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features or characteristics. In particular, preferably the 
operating step includes actions supporting preparation 
of a remote closed-loop-color hardcopy proof, by a print- 
er device that prints and reads a calibration pattern and 
returns a calibration report to an entity in a different lo- 
cation from that printer device. 
[0077] Another basic preference is that the granting 
step occur only if the ASP is an established copartner 
with the RHCPS. Yet another is that the granting step 
include presenting to the user a visible tabulation of that 
user's graphic-arts jobs with the ASP 
[0078] As in the first main aspect of the invention, if 
this visible-tabulation preference is met then it is further 
preferable that the presenting step include opening an 
active graphic-arts dialog window for the user's addition 
or modification of that user's own graphic-arts jobs. If 
this is done, then it is also preferable in turn that the 
opening step include permitting the user to delete that 
user's own graphic-arts jobs, by means of the dialog 
window. 

[0079] Another subpreference to the visible-tabula- 
tion feature is to include the step of maintenance, by the 
RHCPS, of data linking each RHCPS user to each ASP 
with which that user is registered. In this case it is further 
preferable that, for each user, the granting step be per- 
formed only by an ASP with which that user is regis- 
tered. If this registration constraint is in effect, then pref- 
erably the method further includes — for each particular 
job that a user has associated with a particular ASP — 
automatic routing, by the RHCPS, of proof reports and 
related details to the user through that ASP rather than 
to the user directly. This automatic routing, however, is 
not performed if the user specifically instructs the RH- 
CPS to the contrary. 

[0080] In preferred embodiments of its third major in- 
dependent facet or aspect, the invention is a computer- 
ized remote proofing method. It includes the step of op- 
eration, by a user, of a graphic-arts ASP user interface, 
to gain access to data about the ASP's service. 
[0081] It also includes the step of granting, by a 
closed-loop-color remote hardcopy proofing service 
(RHCPS), of access to data about the RHCPS. This 
granting is in response to the user's activation of a link, 
within the ASP interface, to a user interface of the RH- 
CPS — i. e. a reverse link as mentioned earlier. The 
ASP user is also a user of the RHCPS. 
[0082] The foregoing may represent a description or 
definition of the third aspect or facet of the invention in 
its broadest or most general form. Even as couched in 
these broad terms, however, it can be seen that this fac- 
et of the invention importantly advances the art. 
[0083] In particular, this aspect of the invention high- 
lights a second kind of complementary behavior, on the 
part of the ASP, to system establishment and operation 
of the RHCPS. Here a greater burden is placed on the 
characteristics of the ASP's interface. 
[0084] The ASP's interface now is assumed to be suf- 
ficiently user friendly for its customers' purposes — 



whether an elaborate GUI or a type-in console-applica- 
tion syntax or anything in between (multifield reading/ 
entry etc.). For some sophisticated operators, type-in 
syntax is quite sufficient, although for most at least a 

5 multifield control screen is preferable. 

[0085] In this reverse-link environment, the RHCPS 
interface may or may not be invoked: here it is the ASP 
interface that may, if preferred, be allocated all the tasks 
of formatting and presenting the RHCPS data. As will 

10 be understood, for most ASPs there will be no adequate 
motivation to provide this extra service. 
[0086] Some ASPs, however, may want to distinguish 
themselves over their competitors by providing a more- 
helpful interface; or may want to provide a richer look 

15 and feel; or simply may wish to obscure, for their cus- 
tomers, the fact that the service is available through oth- 
er arrangements. All of these variations and also all of 
these motivations are within the overall flexibility, and 
also within the individuality- and competition-enhancing 

20 objectives, of the present invention. 

[0087] Although the third major aspect of the invention 
thus significantly advances the art, nevertheless to op- 
timize enjoyment of its benefits preferably the invention 
is practiced in conjunction with certain additional fea- 

25 tures or characteristics. In particular, preferably the 
granting step occurs only if the RHCPS is an established 
co-partner with the ASP 

[0088] When this is so, then for each user the granting 
step preferably includes displaying a visible tabulation 

30 of that user's jobs that are subject to remote hardcopy 
proofing. If so, then the displaying step preferably in- 
cludes opening an active remote-hardcopy-proofing 
(RHCP) dialog window for addition or modification of 
that user's own RHCP jobs. 

35 [0089] This opening step in turn preferably includes 
enabling the user to delete that user's own RHCP jobs. 
Other preferences described above in relation to the re- 
verse-link preference for the first aspect of the invention 
are applicable here as well. 

40 [0090] In preferred embodiments of its fourth major in- 
dependent facet or aspect, the invention is a method of 
operating a closed-loop color remote hardcopy proofing 
service (RHCPS). The method includes the step of mak- 
ing available a computerized, network-based RHCPS 

45 operated through at least one user interface. 

[0091 ] Another step is, for each project of the RHCPS, 
establishing functioning computerized relationships 
among the RHCPS and entities that include at least a 
primary customer and a printshop. Yet another step is 

50 enabling any of those entities to initiate a project — and 
thereby define default operating conditions that deter- 
mine which of the entities sees, in the at least one user 
interface, each other one of the entities respectively. 
[0092] A still further step is — regardless of which of 

ss the entities initiates the project and defines the default 
relationships — reserving to at least one of the entities 
( i. e. , a participant other than the RHCPS) an option of 
redefining operating conditions to override the default 
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conditions. 

[0093] The foregoing may represent a description or 
definition of the fourth aspect or facet of the invention in 
its broadest or most general form. Even as couched in 
these broad terms, however, it can be seen that this fac- 
et of the invention importantly advances the art. 
[0094] In particular, this aspect of the invention as just 
described provides another key feature that balances 
features associated with the earlier facets. One element 
that is especially helpful here is the preservation of a 
specified participant's control over the relationships. As 
will be seen, selection of the most appropriate partici- 
pant to hold this role may perfect this aspect of the in- 
vention. 

[0095] Although the fourth major aspect of the inven- 
tion thus significantly advances the art, nevertheless to 
optimize enjoyment of its benefits preferably the inven- 
tion is practiced in conjunction with certain additional 
features or characteristics. In particular, preferably the 
"at least one of the entities" — L_e. ! the entity that can 
override the default conditions — includes the primary 
customer. 

[0096] Thus, whereas any of the vendor entities may 
facilitate establishment of the relationships, fundamen- 
tally it is the customer who drives the economics of the 
entire situation and should usually be entitled to recon- 
figure those relationships. A further preference is that 
the method include the step of making available to the 
primary customer information about the option: it would 
be a hollow privilege if the customer didn't know about it. 
[0097] One preferred way of making the information 
available is including in an RHCPS user interface seen 
by the primary customer a link to terms of the RHCPS, 
which include the information about the option. Mere 
presence of such a visible link does not itself unduly 
press upon the customer — particularly a satisfied one 
— the availability of the option. Plainly these principles 
are somewhat in tension, and their proper balance is a 
matter to be carefully considered in configuring the 
wording, graphics and general level of conspicuousness 
of the link and of the customer-override terms, in the 
RHCPS user interface. 

[0098] Another, more-specific preference is that the 
reserving step include enabling the primary customer to 
redefine which of the entities the primary customer can 
see. By operation of this fourth facet of the invention, 
together with these several preferences, the method 
stimulates competition — while tending to deter redun- 
dancy — among enterprises in the printing industry. 
[0099] Previously described preferences, particularly 
relating to the types of entities involved, are applicable 
for this fourth aspect of the invention too. As noted ear- 
lier, the several independent aspects of the invention are 
most advantageously all practiced together. 
[0100] In preferred embodiments of its fifth major in- 
dependent facet or aspect, the invention is a method of 
operating a closed- loop color remote hardcopy proofing 
service (RHCPS) that stimulates competition while 



tending to deter redundancy, among enterprises in the 
printing industry. This method includes the step of mak- 
ing available a computerized, network-based RHCPS 
operated through at least one user interface. 
5 [0101] Another step is, for each project of the RHCPS, 
establishing functioning computerized relationships 
among the RHCPS and entities that include at least a 
primary customer and a printshop. Still another step is 
enabling any of the entities to initiate a project and there- 
jo by define default operating conditions that determine 
which of the entities sees, in the at least one user inter- 
face, each other of the entities respectively. 
[0102] Yet another step is — regardless of which of 
the entities initiates the project and defines the default 
is relationships — reserving to the primary customer an 
option of redefining operating conditions to override the 
default conditions. A further step is making available to 
the primary customer information about the option, by 
including the information in the at least one user inter- 
na face or in separate communications to the primary cus- 
tomer. 

[0103] The foregoing may represent a description or 
definition of the fifth aspect or facet of the invention in 
its broadest or most general form. Even as couched in 

25 these broad terms, however, it can be seen that this fac- 
et of the invention importantly advances the art by ex- 
pressly preserving a proper position of the primary as in 
control, while allowing vendors great latitude in individ- 
ual style and character of operation — as long as, ba- 

30 sically, the primary feels well treated. Preferences here 
are closely related to those introduced earlier. 
[0104] In preferred embodiments of its sixth major in- 
dependent facet or aspect, the invention is a user inter- 
face for a closed-loop color remote hardcopy proofing 

35 service (RHCPS). The interface includes RHCPS input/ 
output elements for gaining access to a computerized, 
network-based RHCPS. These input/output elements 
are also for entering data and instructions into the RH- 
CPS, or reading data and status from the RHCPS — or 

40 both. 

[0105] The interface also includes application service 
provider (ASP) input/output elements for each project of 
the RHCPS. These elements reflect functioning compu- 
terized relationships among entities that include the RH- 

45 CPS and at least one ASP. 

[0106] The foregoing may represent a description or 
definition of the sixth aspect or facet of the invention in 
its broadest or most general form. Even as couched in 
these broad terms, however, it can be seen that this fac- 

50 et of the invention importantly advances the art. 

[0107] In particular, this interface provides a basic 
building-block mechanism for accomplishing the sever- 
al advances discussed in relation to the first five as- 
pects. Preferences are closely identifiable with prefer- 

55 ences for those earlier-introduced aspects. 

[0108] As mentioned earlier in connection with the 
first independent aspect of the invention, the interface 
is not necessarily a graphical user interface ("GUI"), al- 
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though this may be preferred for some types of users. 
Rather the interface may take any of a great variety of 
forms, especially including the classical DOS- or Unix- 
style control screens with multiple data-display or -entry 
fields but no icons or other elaborate graphics. As is well 5 
known, such forms are orders of magnitude more effi- 
cient in terms of using computer resources — particu- 
larly including considerations of speed, storage, and re- 
liability. 

[0109] All of the foregoing operational principles and io 
advantages of the present invention will be more fully 
appreciated upon consideration of the following detailed 
description, with reference to the appended drawings, 
of which: 

15 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0110] 

Fig. 1 is a diagram, highly schematic, of a repre- 20 
sentative hardware system according to preferred 
embodiments of the invention; 
Fig. 2 is a picture of a graphical user interface (GUI) 
for a printshop using the remote hardcopy proofing 
service (RHCPS), in the case of a direct customer- 25 
to-printshop relationship — and particularly where 
the customer is the first RHCPS customer of that 
shop (or where the shop operator has already se- 
lected the customer from among plural customers); 
Fig. 3 is a picture of. a related interface screen for 30 
choosing a job-selection log-in mode, where the 
customer is not the first RHCPS customer for the 
shop — or for proceeding directly by customer, job- 
ticket number, JDF, or date, if the system designers 
prefer to include such parameters (and default val- 35 
ues) in this mode-selection screen; 
Fig. 4 is a picture of an interface screen resulting 
from the above-described choice of mode, and dis- 
playing a list of customers; 

Fig. 5 is an alternative screen like Fig. 3 but without 40 
the default parameter-entry fields; 
Fig. 6 is a screen that appears — if the operator 
selects the JDF job-ticket entry mode in Fig. 3 or 5, 
but in Fig. 3 fills in no JDF number — for presenta- 
tion of the data field for log-in by JDF job-ticket 45 
number; 

Fig. 7 is a screen like Fig. 2, but including inactive 
jobs; 

Fig. 8 is a GUI screen showing setup for semiauto- 
matic progression of a job from proof ing-file prepa- so 
ration to transmission, nominally using a hot folder; 
Fig. 9 is a GUI screen for an operator's use in man- 
ual movement of the file into a hot folder; 
Fig. 10 is a screen like Fig. 9, but for the operator's 
use in only confirming automatic movement into the 55 
hot folder; 

Fig. 11 is a picture like Fig. 3 for the same case but 
for use by the customer, at the customer's facility, 



rather than for use by the shop; 
Fig. 12 is a picture of the GUI screen, analogous to 
that of Fig. 2 and for the same case of a direct cus- 
tomer-to-shop relationship, but displaying the job 
list as the customer (rather than the printshop) sees 
it upon log-in through the Fig. 11 screen; 
Fig. 1 3 is a set of three views of a log-in GUI dialog 
like Fig. 3 in that it is for use at the printing house, 
and for job selection — but for the case of a proofing 
ASP added to the parties in the relationship — and 
particularly showing three exemplary link precur- 
sors ( I. e. , reflecting knowledge of an ASP's being 
involved in at least one of the printshop's jobs): in 
the "A" view, displaying the log-in choices within da- 
ta fields; in the "B" view, displaying them as an in- 
tegral part of the GUI itself, with radio buttons or 
check-boxes; and in the "C M view showing the choic- 
es in an even more structurally integrated way, with 
labeled click-buttons; 

Fig. 14 is a set of four examples of a screen that 
may follow after job selection, le^ once it is known 
whether an ASP is involved in the particular job se- 
lected — the operator can connect into the system 
through the ASP (rather than directly) if preferred, 
and this can be indicated by clicking, as in the "A" 
view, on a minimal kind of link (an ordinary URL- 
style hyperlink) from the printshop to the ASP site; 
or as in the "B" view, using an intermediate level of 
link (displaying the choices within data fields); or as 
in the "C" view, using a still higher level of link (dis- 
playing the log-in choices as an integral part of the 
GUI itself — with radio buttons or check-boxes); or 
as in the "D" view, showing another exemplary link 
form that is more highly preferred, a maximal level 
of link integration (displaying the log-in choices as 
an even more structurally integrated part of the GUI 
— with labeled click-buttons); 
Fig. 15 is a picture like Fig. 14D, but for the GUI 
seen by the primary customer rather than operators 
at the printing house; 

Fig. 1 6 is a picture like Fig. 2 — which is to say, for 
use by an operator at the production house — but 
for the Fig. 13 and 14 case of a proofing ASP in- 
cluded in the parties, together with the customer 
and printing shop; 

Fig. 1 7 is a GUI data-display picture like Fig. 1 6, but 
for use by the customer rather than the printshop; 
Fig. 17A is an alternative to Fig. 17, a display that 
may be provided if one of the vendors — here the 
proofing ASP — has been principally responsible 
for RHCPS arrangements with the primary custom- 
er and wishes to link the customer to that vendor's 
own GUI rather than the standard RHCPS interface 
(the vendor's interface in the example being a h£ 
brid with the standard RHCPS interface); 
Fig. 18 is a GUI data-display picture like Figs. 16 
and 1 7 but for use by the proofing ASP rather than 
the customer or shop; 



11 



21 



EP 1 262 748 A2 



22 



Fig. 19 is a picture like Figs. 2 and 16 (i. e. , once 
again for use by an operator at the printing house), 
but for the case of a private-network ASP added to 
at least the first two of the three parties assumed in 
Fig. 16; 5 
Fig. 20 is a picture like Fig. 19, but once again for 
the customer; 

Fig. 21 is a picture like Fig. 19 and 20, but again for 
the proofing ASP if participating; 
Fig. 22 is a picture like Figs. 1 9 through 21 . but now 10 
for the network ASP; 

Fig. 23 is a picture like Fig. 19 ( i. e. for use at the 
printshop), but for the case of a middleman or trans- 
action ASP added to at least the first two of the par- 
ties assumed in Fig. 19 — and also incorporating 15 
yet another party such as an outside prepress 
house, supplementing the efforts of the final offset 
shop (any other type of specialty service may be 
substituted where there is room in the GUl : or by 
adding a horizontal scroll bar for further partici- 20 
pants); 

Fig. 24 is a picture like Fig. 23, but for use by the 

customer rather than the printing house; 

Fig. 25 is a picture like Figs. 23 and 24 : but for use 

by the proofing ASP if participating; 25 

Fig. 26 is a picture like Figs. 23 through 25, but for 

use by the network ASP if participating; 

Fig. 27 is a picture tike Figs. 23 through 26, but for 

use by the transaction ASP; and 

Fig. 28 is a screen with a link to contract terms. 30 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

1 . OPEN COVENTURING, WITH PRESERVED 35 
CLIENTELE 

[0111] Preferred embodiments of the invention ena- 
ble the several types of participants in the printing in- 
dustry to use a service such as a remote hardcopy proof- 40 
ing service (RHCPS) — and in fact services of any of 
certain other ASP copartners, and any other vendors 
that are registered in the system — with only a reason- 
ably minimal concern for the possibility of clientele lost 
to competitors as a direct result of participation in the 45 
service. Yet each client, customer, and in fact each par- 
ticipant at any level, is always free (subject to separate 
contractual constraints, of course) to change allegianc- 
es at will, provided only that the client exercises initiative 
to find a preferred vendor through means other than be- so 
havior of the copartnering ASPs. 
[0112] For example the yellow pages phonebook., or 
a trade directory, can always be used to actively seek 
an alternative vendor for any of the services involved. 
None of the copartnering entities or other registered ss 
vendors can reasonably expect to prevent such efforts 
on the seeker's own initiative, unless the customer and 
vendor have entered into an exclusive service contract 



of some sort. What is, however, disfavored is subversion 
of the objectives of copartners and vendors through se- 
ductions on the part of the copartnering application serv- 
ice providers themselves. 

[0113] These benefits are produced for the partici- 
pants by programming into the service infrastructure a 
capability to recognize which of the participating busi- 
ness entities it was that introduced each primary cus- 
tomer to each component, respectively, of the overall 
interlinked service. That customer is thereafter associ- 
ated with that introducing entity, or array of introducing 
entities — unless the customer itself undertakes to re- 
vise the association. 

[0114] In computer jargon, the customer and the in- 
troducing entity are associated simply as a "default" . As 
those in the programming field know, the quoted word 
means that this association is the operating assumption, 
in the absence of contrary information — which can be 
entered into the system databases by one or more of 
the parties, perhaps using some other menu and dialog 
window. 

[01 1 5] This arrangement does not imply that the cus- 
tomer's ability to make such revisions should be kept a 
secret from the customer. In fact that way of operating 
would not be fair to service participants other than the 
initially introducing entity. To the contrary, in preferred 
embodiments of the invention the customer's option of 
reconfiguring the basic relationships is part of the terms 
of the RHCPS and is available to be read at some ap- 
propriate level in, for example, the "help" screens of the 
service. 

[0116] For example, a particular printing house that 
signs on for use of the RHCPS should ordinarily be en- 
titled to use it for any primary customer that elects to 
buy printing from that particular house — including one 
that wishes to transfer its business from some other 
printshop. To provide the primary customer less flexibil- 
ity than that would be rather contrary to the general prin- 
ciple of free enterprise and possibly subject to legal 
sanction. 

[0117] Ideally a proper balance is maintained be- 
tween, on the one hand, preserving the customer's right 
to know that such options are available; and, on the oth- 
er hand, undermining the copartners and other partici- 
pating vendors by pushing such options onto the cus- 
tomer. In effect the system as thus configured imple- 
ments basic traditional trade courtesies on the part of 
printers, ad agencies, graphic artists and ASPs alike — 
i. e. to refrain from rudely abusing a complementary en- 
terprise in return for a kind referral by sending the cus- 
tomer off to some competitor of the referring enterprise. 
[01 1 8] In the classical scheme of things, if a customer 
expressed to the initial beneficiary of a referral an active 
discontent with services of the referring entity — then 
the initial beneficiary would be faced with a difficult pro- 
fessional and interpersonal task. This might call for bal- 
ancing kind words for the referring entity with sugges- 
tions to the customer (based upon principled reasoning 
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as to the substance of the situation rather than person- 
alities) that perhaps, "for this type of project", a larger 
enterprise, or smaller one, or differently specializing 
one, might be more appropriate. (If done well, this be- 
havior might in truth benefit even the initially referring 
entity, if in fact that entity and the customer were a poor 
match based upon size, specializations or the like; for 
the referring entity constantly might be expending extra 
resources in a hopeless effort to please a customer who 
represented only marginally profitable business.) 
[0119] That sort of delicate weighing and discreet 
choice of wording is generally unavailable in the con- 
ventional electronic-commerce environment; hence the 
problem outlined in an earlier section of this document. 
Preferred embodiments of the invention therefore con- 
struct an alternative mechanism for striking a different 
kind of balance, which approximates the classical trade 
courtesies without demanding so much of the participat- 
ing vendors. In this way the invention exploits an easily 
practiced technological solution to reintroduce and 
maintain a special kind of professional integrity within 
the e-commerce segment of the trade. 

2. NETWORK ENVIRONMENT 

[01 20] The technology itself while novel in application 
is relatively straightforward technologically, as suggest- 
ed by the earlier discussion of integrating software pe- 
ripherals into a major word-processing program. The 
present invention contemplates establishment and op- 
eration of an RHCPS 11 (Fig. 1) over two or more net- 
works — one being the Internet 16, for those partici- 
pants who are satisfied with that level of service; and 
another being at least one private network 25 such as 
that operated by the company called "Warn! net". 
[0121] In general, transactions and services between 
particular customers, vendors and e-service entities 
may proceed partly by Internet and partly by private net- 
work, to the extent that those participants prefer; or may 
instead be entirely on the Internet or entirely on a private 
network. Users gain access to the most-local portion of 
the selected network by traditional phone dial-up, or by 
DSL-style or cable-modem connection, or by ports con- 
nected directly to high-speed optic-fiber or coaxial lines 
that are linked directly to the network backbone. 
[0122] A primary customer 12 may itself initiate ar- 
rangements for connection and commerce with the RH- 
CPS or other participant 1 3, 21 -24 directly — or one of 
the other participants (the RHCPS, or other ASP 22, 24, 
25, or a trade vendor) may offer to set up the customer's 
initial connections to get the customer started. As a 
practical matter, all or substantially all the relevant serv- 
ices involve interconnection of apparatuses, L_e. equip- 
ment, of the respective participants: these devices may 
range from a common personal computer for soft proof- 
ing to an extremely specialized prepress ("PP") facility 
23, or inkjet proofing printer 14, 15; or to network equip- 
ment itself. 



[0123] An underlying objective of preferred embodi- 
ments of the invention is to preserve the value of busi- 
ness-generating efforts by all and any participants, L_e. 
of entrepreneurial industriousness and goodwill. At the 

5 same time these embodiments preserve a maximum de- 
gree of utilization of available technology, for the benefit 
of all involved, ms. for maximum interoperability of the 
several systems involved. As suggested earlier, the rel- 
atively op en -structured but essentially coventuring rela- 

10 tionship of entities that is established in preferred em- 
bodiments of the invention tends to deter less-salutary 
motivations, e. g. for piracy, parasitic behavior and the 
like. 

[0124] Shown connected to the networks in Fig. 1 are 

15 examples of the several types of participants in pre- 
ferred embodiments of the present invention. These typ- 
ically include the principal participants in a basic graph- 
ic-arts transaction, namely the customer 12, printshop 
13 and RHCPS 11. 

20 [0125] In event those are the only participants, then a 
local proofing printer 14 may be housed at the printshop 
13 itself rather than in a separate enterprise as illustrat- 
ed; and a remote proofing printer 15 may be housed at 
the primary customer's facility 12 rather than elsewhere 

25 as also illustrated. Nevertheless both the local and re- 
mote printers are labeled as "RP" (remote proofing) de- 
vices because they preferably are both units in a product 
line of inkjet printers particularly designed and optimized 
for consistent and reliable closed-loop-color perform- 

30 ance in an overall remote-proofing environment. 

[0126] Ideally the two printers are essentially identi- 
cal, and preferably Hewlett Packard products. The prin- 
cipal users 12,13 can be connected entirely through the 
Internet 16, or entirely through a private-network ASP 

35 25; or as suggested partway through one and partway 
through the other. In such a hybrid network configura- 
tion, the interface between the two nets is not necessar- 
ily at the facility of some other participant (as shown), 
but rather may instead at a terminal box or other facility 

40 maintained by, e. g. , the network ASP. 

[0127] Many other possible combinations of partici- 
pants are possible and frequently encountered in oper- 
ation of the RHCPS. The example illustrated includes a 
relatively full complement of such participants: a pre- 

45 press house 23 associated with the printshop 13 and 
possibly providing the local proofing equipment 14; and 
a graphic arts ("GA") house 21 or ad agency etc. some- 
what more closely associated with the customer 12. 
[01 28] The PP and GA enterprises may be computer- 

so jzed services, l_e. e-commerce ASPs, but in their most 
common forms they are instead conventional business- 
es. For example much or most of the communication 
and materials passing between the primary 12 and the 
GA 21 are commonly implemented by traditional meth- 

55 ods26 — telephone, or courier or actually going to see 
one another, or the like. 

[0129] More commonly taking the form of ASPs are 
the other participants illustrated: a soft-proofing ASP 22 , 
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enhancing its services by maintaining a remote RP de- 
vice 15 and serving also as a terminal for the RHCPS 
11; a broker or middleman ASP 24, here also called a 
transactional ASP (transASP); and the private- network 
ASP 25. In the particular configuration shown, neither 5 
the primary 12 nor the GA 21 has a remote-proofing de- 
vice; hence they depend on the soft-proof ASP 22 and 
perhaps typically use traditional methods 27, 26 in mak- 
ing arrangements for and in retrieving the hardcopy 
proof, carrying it to the primary 12, and giving approval. 10 
[01 30] Emphatically, these methods can be bypassed 
if the primary or GA, or both, prefer to invest in equip- 
ment 15 for receiving and viewing proofs in-house. 

3. COMPONENTS OF PREFERRED EMBODIMENTS 15 

[0131] For successful operation, it has proven helpful 
to provide certain distinct elements — listed below — 
in preferred embodiments of the invention. This should 
not, however, be mistaken as meaning that all these so 
components are required: 

■ availability of a printer device able to do closed-loop 
remote hardcopy proofing (RHCP), including auto- 
matic return of a definitive report on color reproduc- ss 
ibility — and preferably absolute accuracy — in 
perceptual or colorimetric terms, or both; 

■ emplacement of a hardware infrastructure for car- 
rying data — including queries, approvals, excep- 30 
tions and so on — among or between defined par- 
ticipants; 

■ establishment of a standardized document-content 
format which is widely available to industry partici- 35 
pants — and which is amenable to streamlining for 
efficient and unambiguous specification of images 

to be proofed; 

■ parallel establishment of a standard job-definition 40 
format — also amenable to streamlined specifica- 
tion, but of overall commercial/industrial processing 
steps; and 

■ a workflow-management protocol or component ^ 
that defines the participants, shapes and constrains 

all their interactions, and thereby integrates the 
above components to implement the RHCP objec- 
tive. 

50 

[0132] In most-highly-preferred embodiments of the 
invention, the printer device is a Hewlett Packard prod- 
uct that has the above-mentioned RHCP functions built- 
in. The hardware infrastructure, for reasons already 
suggested, is ideally a hybrid of Internet and participat- 55 
ing private networks — which latter can be operated by 
ASPs as noted earlier. 

[0133] One of the network subelements is preferably 



an electronic "gateway" or file-server infrastructure op- 
erated by the Hewlett Packard Company or other man- 
ufacturer of the printer device. This subelement helps to 
ensure a proper interlinking of the printers, their updat- 
ing with software upgrades from time to time, and over- 
seeing of their color-calibration maintenance and basic 
operating integrity. 

[0134] The document-content format preferably is a 
portable document file ("PDF") of the Adobe company 
— but with a stringently reduced parameter set, for 
streamlining, as will be exemplified in a later section of 
this document. The job-definition format is likewise a re- 
duced-parameter version of the industry's job definition 
file ("J DP). 

[0135] Modernly the PDF specification has branched 
into other standards definitions, based on PDF, and par- 
ticularly including PDF/X-1 and PDF/X-3. These speci- 
fications go along the same general lines of restricting 
the types of data and parameters that can be used: and 
in fact one highly preferred embodiment of the invention 
now uses the PDF/X3 specification. 

(a) Workflow protocol features — The "workflow 
management protocol", on which the present patent 
document particularly focuses, in turn preferably 
has key features: 

(1 ) a delicately defined set of rules that interlink 
diverse participating entities and strike a care- 
ful balance among certain competing meas- 
ures of fairness, loyalty, and autonomy — in an 
intuitively acceptable way; 

(2) an interentity interface-sharing technique 
that implements those rules in a manner which, 
once again, represents a fine balance between 
discreet, decorous conduct of business and an 
open, nonsecretive regime; 

(3) support of JDF-based workflow in the ab- 
stract; 

(4) notification of job activity to relevant partic- 
ipants; 

(5) logging of job activity; and 

(6) a user interface — preferably but not nec- 
essarily a graphical interface, e.g. based on ex- 
tensible markup language (XML) — that is 
compatible with the inter-entity interface-shar- 
ing objective — while interacting with all inter- 
ested users to expedite the entry, retrieval, 
modification and use of all the information in the 
system. 

[0136] As to feature (1) in this list, the principles of 
loyalty and autonomy are intrinsically in tension with 
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each other; in other words, they trend oppositely — and 
the principle of fairness is a kind of moderating influence 
that may keep them from tearing each other apart or de- 
stroying potentially beneficial business relationships. As 
to feature (2), analogously, discreet and decorous be- 
havior trend in directions that often conflict with open- 
ness or nonsecretiveness. 

[0137] In preferred embodiments, the workf low-man- 
agement protocol is not complex so much as it is care- 
fully contoured, at difficult points — so as to accomplish 
the desired balancing of the contrary -trending business 
and societal considerations that have been introduced 
here. 

[0138] Features (3) through (5) in the list are more 
mechanistic. They essentially represent backbone 
chores that the procedures should accomplish. Feature 
(6), a programmed computer interface used directly by 
all or most participants in the system, is at once a me- 
dium of communication, an automatic implementer of 
the mechanistic tasks, and an enforcer of the rules and 
the technique. 

(b) Proofing ASPs (or primary customers) and the 
work protocol — A service ASP that wishes to offer 
a remote-proofing service to its own customers can 
use the workflow-management component or pro- 
tocol of the present invention to delegate the man- 
agement of proof status, as will be explained short- 
ly. In such a situation the ASP infrastructure can i^ 
self implement the following functions, or parts of 
them. 

■ the method for sharing a proof between the 
originator and the receiver or receivers, possi- 
bly using different models — for example, a 
mailbox for each user or a shared working site 
on the network 

(The corresponding element in the clas- 
sical environment, previously mentioned, is the 
printer's makeready room, with its job bins and 
sometimes an adjacent conference room.) 

■ the transport method and protocols for the proof 
files, for example provision of a high-bandwidth 
private network to connect users 

(The classical analog of this element, al- 
so mentioned earlier, is a courier.) 

■ the method or methods for interaction between 
the final user and the interfaces provided ac- 
cording to the invention 

(Here the earlier-noted classical analog is 
work of the prepress manager, or the business 
proprietor, or a salesman.) 

■ integration with other services provided by the 
ASP, such as digital-asset management 

(This function corresponds to file cabi- 



nets, or a safe-deposit box, or a vault — for 
holding archival plates, negatives and artwork.) 

[0139] The ASP, however, would delegate the man- 
5 agement of the proof jobs to the workflow-management 
component (or protocol) of the present invention. As 
stated in an earlier section, this workflow- or proof-man- 
agement function consists of knowing and changing (1 ) 
the status of the proofs, and (2) possible actions that 
10 can be performed on a proof job at any given moment. 
[0140] The service ASP is therefore free to establish 
a system and protocol that are independent of the de- 
tails of the "life cycle" of a proof. These elements of the 
ASP's operations need not be changed when proof- 
's management details are changed. 

[0141] The workflow-management protocol or com- 
ponent of the present invention provides an interface 
that is based on, but moves beyond, industry-standard 
hypertext transfer protocols (HTTP) and extensible 
20 markup language (XML), to provide three groups of 
functions: 

■ proof activity — The ASP uses these functions 
whenever an action is to be taken on a proof . as for 

25 example when a user uploads a proof document to 
the ASP service. The actions are used as input by 
the workflow-management component and may 
cause changes in the status of proofs. 

30 m proof status queries — The ASP can perform que- 
ries on the status of a certain proof or a set of proofs. 
The workflow-management component provides 
replies, which the ASP can use to provide informa- 
tion to the primary customer. 

35 

■ proof event notifications — These events are initi- 
ated by the workflow-management component it- 
self, to notify the ASP and its client of changes in 
status of a proof job. 

40 

While these functions represent a relatively high degree 
of interaction between the ASP and the workflow-man- 
agement component — as to details of a proofing 
project — that is true in large part because this first ex- 

^5 ample discussed here is for a proofing-service ASP. 
[0142] As indicated previously, upon logging on to the 
RHCPS the service ASP sees only its own projects — 
and, once the particular customer involved has been 
identified, sees only its own projects with that customer. 

so This is normally true even if the same customer has 
projects with, for instance, other service ASPs. 
[0143] In many cases such an ASP operates essen- 
tially on behalf of a primary customer. A generally com- 
parable degree of close interaction occurs if the work- 

55 flow-management protocol is operated by the primary's 
own technical people directly, rather than through the 
ASP. 

[0144] As seen in the following subsections, however 



25 



15 



29 



EP 1 262 748 A2 



30 



the workflow-management component is also capable 
of interacting with other types of ASPs beneficially but 
much less intimately than described above. 

(c) Transaction ASPs (or buyers) and the work pro- 
tocol — A broker agent, intermediary, middleman, 
matchmaker or other print-transaction ASP 
(transASP) can use the workf low-management 
component or protocol of the present invention in 
ways generally analogous to those described 
above. Such a transaction ASP. however, most 
commonly does not wish to set up full remote proof- 
ing capabilities in its environment. 

[01 45] The focus of a transASP is in fact the commer- 
cial aspects of the industry rather than the operational 
aspects. Accordingly the transASP more commonly pre- 
fers to use remote proofing services provided by service 
ASPs to supply operational functions for the transaction- 
al service. 

[0146] In this case, most transASPs, using the work- 
flow-management protocol or component of the present 
invention, do not care to know specific details of the re- 
mote proofing service operations provided by the serv- 
ice ASP. The transASP can use several different ASPs 
simultaneously for different clients or even for different 
projects of a common client. 

[0147] A transASP that does not implement its own 
remote-proofing service most typically uses only the 
proof status query interface module (mentioned in the 
preceding subsection), to occasionally consult informa- 
tion about proof status. The transaction ASP usually 
does not want to see the proof, or its approval, or any 
other related activity unless the transaction is in danger 
of failing. 

[01 48] At that point, however, the transaction ASP — 
if a participant in the RHCPS — at its own facilities can 
log on to the service. The transaction ASP can then 
quickfy determine whether and exactly when proof ma- 
terial was transmitted to the proofer, when and how a 
proof was returned, what response was made upon in- 
spection of the proof by the authorized party, and there- 
by generally just when, how and why the process may 
have broken down. 

[0149] Concerned for the satisfaction of its client, up- 
on which a commission ordinarily depends, the transac- 
tion ASP can promptly and efficiently learn what might 
be done to put the transaction back on track to comple- 
tion. To accomplish this, as in the other situations de- 
scribed in this document, the transaction ASP will not 
have to search through many entries pertaining either 
to its competitors, or to transactions that happen to use 
no transactioh ASP at all, or to transactions with the 
same printer but other customers of the same ASP, or 
perhaps even to transactions which the same customer 
may have placed with a different transaction ASP. 
[0150] Rather, the transaction ASP simply need iden- 
tify its own customer. The ASP then sees only relevant 



projects.. L_e. its own projects with that customer. 
[0151] A similar degree of arm's-length interaction 
with the workflow-management component of the 
present invention may be appropriate for, e.g. , the busi- 
s ness manager or financial officer of a primary customer 
using the RHCPS of the present invention — where the 
primary customer's technical people are operating the 
protocol directly as mentioned at the end of the last sub- 
section. 

w 

(d) Transport ASPs (or IT managers, or couriers) 
and the work protocol — Yet another kind and de- 
gree of interaction arises between the workflow- 
management component of the present invention 
15 and a different entity entrusted with transmission of 
proofing materials for use in proofing, or with return 
delivery of a proof for viewing. This sort of interac- 
tion is ordinarily limited to information about the 
transmission or delivery itself, a function that usu- 
20 ally arises only when some aspect of those events 
is not fully automatic. 

[01 52] For instance, if the primary customer or a serv- 
ice ASP has elected to use the services of a transport 

25 ASP (private network operator) for such transmissions 
and deliveries, ordinarily the transport ASP in such 
workflow is transparent — and also essentially content 
neutral. The transmitting entity logs on to the network in 
a generally conventional (and usually automatic) way, 

30 and sends; the receiving entity logs on likewise and re- 
ceives. 

[0153] Ordinarirythereisno need to otherwise contact 
or communicate with the transport ASP. If, however, de- 
liveries fail because the connection drops out or is noisy 

35 during transmission — or if the sender believes that 
transmission was complete but the recipient does not 
have the file — then they can query the transport ASP 
[0154] In preferred embodiments of the invention, if 
the transport ASP is an active coventurer in the RHCPS, 

40 then that ASP can supplement its usual procedures for 
checking into such situations. Specifically, and very ad- 
vantageously, at its own facilities the ASP can log on to 
the RHCPS interface to inspect technical data about the 
transmission. 

45 [01 55] Where there has actually been any passage of 
data to the private net, the transport ASP can see log- 
ins by the sender, associated with traceable information 
about the transmission to see what happened next. This 
level of interaction with the service is comparable to the 

50 contact which occurs if the sender is in a large firm with 
its own "information-technology" (computer) depart- 
ment, and the sender contacts that department to inves- 
tigate a failed transmission. 

[0156] Another example of the same degree of con- 
55 tact is the relatively unlikely instance of a buyer, pre- 
press service etc. that actually uses a courier service to 
complete proof delivery through the last leg of a delivery 
chain, to a primary customer who is not on-line at all. In 
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that case the entity which logs on to determine status 
may be the courier service. 

[0157] In these various situations, as in the earlier 
sections and subsections of this document related to in- 
teractions with the workflow-management component 
of the RHCPS, what the courier, or IT department, or 
transport ASP sees tabulated is only its own relevant 
tasks with relevant parties. This is ordinarily the case 
even if those parties are engaged in other projects using 
other couriers, or other transport ASPs, respectively. 

(e) Advantages of the workflow-management com- 
ponent of the RHCPS — The service thus promotes 
and enhances cooperative coexistence and com- 
plementary operations by separate (as opposed to 
vertically integrated) small and large printshops, 
ASPs, primary customers, and incidental service 
firms such as manual couriers. While the primary 
customers and indeed all of the participants are at 
liberty to realign themselves with other participants, 
the RHCPS does not encourage them to do so. 

[0158] If a printshop wishes to use the RHCPS to 
transmit data for proofs, and actually create proofs, for 
customers, the printshop can do so without concern that 
the customer — in the actual process of checking 
projects with that printshop — will see the names of 
competing printshops. If the customer were directly led 
by the RHCPS to see those competitors, the printshop 
might be disposed to make other remote-proofing ar- 
rangements. 

[0159] On the other hand, if a customer on its own in- 
itiative wishes to search the RHCPS for participating 
printshops, the customer is able to do so. All the same 
can be said of ASPs and incidental services that has 
been said of printshops. 

[0160] In this way the operating rules of the service 
promote — but do not enforce — loyalty within the 
trade. Participants in promoting their own services, 
whether by direct one-to-one marketing contacts or by 
media advertising, are at liberty to advertise that they 
can provide remote hardcopy printing through the RH- 
CPS. 

[0161] This protocol thus tends to mitigate and some- 
times resolve the previously outlined difficult problems 
within the industry. In this way the service benefits the 
economy in general and the several different kinds of 
participants in particular. 

[0162] Further, the workflow-management compo- 
nent is advantageously centralized for use by plural dif- 
ferent remote proofing services. In this situation the pro- 
tocols can be adapted to take advantage of the operat- 
ing characteristics of specific proofing printers. To con- 
sider a case in pertinent point, when a printer is manu- 
factured to perform remote closed-loop color opera- 
tions, the service can be programmed to facilitate such 
operations. 

[0163] More generally the service can be refined or 



enhanced internally without requiring any change by 
participants. The latter simply are free to benefit from 
whatever additional services or features the RHCPS 
brings on line — as for instance to support new proof- 

5 printer features. 

[0164] By virtue of sharing a common job model, or 
workflow-management protocol, different remote-proof- 
ing services can be interoperable. Proofs created by a 
user in one service can be used by users in other serv- 

10 ices. 

[0165] If a proofing service chooses to provide its own 
user interface to its users, each of those users can op- 
erate with that particular distinctive interface — without 
needing to know details of features in a counterpart 

15 service. Yet plural counterpart proofing services using 
the centralized RHCPS can communicate with each oth- 
er through the RHCPS's master interface, sharing and 
trading excess capacity, overflow work, jobs requiring 
specialized capabilities, etc. — for the benefit of all. 

20 [0166] The RHCPS also has the benefit of naturally 
giving users of every type only the information those us- 
ers require or want. For instance a transASP — perhaps 
using the workflow-management component simply to 
obtain a proof-status report — need not know details of 

25 the remote proofing services being used. 

4. USER INTERFACE 

[0167] This section takes up the element identified as 
30 (6) in subsection 3(a) above. A journeyman programmer 
of ordinary skill can straightforwardly create this inter- 
face. 

[0168] Its craftsmanly execution is key to success, 
since most of the advantages discussed above depend 

35 upon implementation of the stated principles by the user 
interface itself. For purposes of definite ness the follow- 
ing presentation will show and discuss a graphical user 
interface ("GUI"), but as noted elsewhere in this docu- 
ment a much less resource-demanding user interface 

40 can be used instead. An overall benefit of the invention 
is that the objectives and principles are easily but direct- 
ly embedded in a DOS/Unix-style interface or in a GUI 
as preferred. 

[0169] Once that is done, those objectives and prin- 
ts ciples become in essence self-fulfilling as the users col- 
lectively operate the system from that interface through 
their respective computers. Here are examples for sev- 
eral different cases: 

so (a) Primary customer direct to printshop — Sup- 
pose that a primary customer uses no intermediary 
ASP and has sent materials for a printing job to a 
printing house directly, and the customer itself has 
a proofing press at its own facility. When that print- 

55 shop has the proofing file ready, the shop personnel 
log onto the RHCPS. 

[01 70] If this is the shop's first-ever RHCPS customer 
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(direct or indirect), then the RHCPS interface simply dis- 
plays the name of that customer and a list of all that cus- 
tomer's jobs (Fig. 2): otherwise, the shop's operator 
looks on the screen for the direct customer, either: 

5 

■ searching by name in a list of established custom- 
ers (moving from the screen of Fig. 3, solely for se- 
lection of finding-by-customer mode; to that of Fig. 
4 for actual entry of initials for. and/or scrolling to : a 
particular customer); or 10 

■ manually typing in the direct customer's name in a 
data-entry field (Fig. 3). 

[0171] In the first, mode-selection screen, the specific '5 
default entries (the entries last used) are grayed out for 
the mode options next to inactive radio buttons. In the 
option next to the active button (here "customer"), the 
default entry appears in reverse characters on a dark 
field, as shown — so that an operator who wishes to 20 
return to that entry can do so simply by clicking "OK" or 
pressing "Enter" on the keyboard. If instead the operator 
types anything in that field, the reverse-character default 
entry disappears and the operator's entry appears in 
normal (not reverse) characters. 25 
[01 72] Searching in a list (the first option noted above) 
is often better, to avoid using a nonstandard or nonpre- 
ferred form of the customer's name; nevertheless the 
second, type-in option may be preferred by fast typists, 
and can be used even if the customer is an established 30 
customer of the shop. In that event, however, the system 
ordinarily completes the customer's name based upon 
the operator's entry of just the first few letters — as is 
nowadays familiar in the address-book functions of e- 
mail handling programs and the like. 35 
[0173] In either case the RHCPS interface responds 
with a listing (Fig. 2) of all of that customer's projects — 
and also, at the top, information about the customer and 
the printshop itself. This upper part of the display indi- 
cates by headings and also by font distinctions which 40 
data are for the customer and which for the printshop. 
To further keep these differences very clear, the print- 
shop data (at right) may be displayed as an integral part 
of the virtual control panel pictured on the screen, while 
the customer data (at left) may instead appear within a 45 
data subwindow as shown. 

[0174] The displayed listing includes several key pa- 
rameters of the current project, for ready reference — 
but not all of the parameters for that project. Such a fuller 
tabulation would typically occupy a large fraction of the so 
screen for just one project, and would contain many 
pieces of data interesting only to prepress technicians 
at the printshop, or proofing technicians at the proofing 
facility. A full or categorized partial tabulation for any 
project of the current customer is available to the oper- 55 
ator upon operating a related control in the RHCPS in- 
terface — such as the buttons marked "details/edit" in 
the bottom half of Fig. 2, at left of the individual job en- 



tries. 

[0175] Much of the displayed data may be in the da- 
tabase of the RHCPS. Certain other data, however, 
available in the fuller tabulation — or even in the abbre- 
viated summary (Fig. 2) — may instead reside in the 
computers of the printshop itself or of the primary cus- 
tomer. 

[0176] Those data are called up by links into the 
shop's or customer's own site. The customer's reference 
number ("HU-241 ") in the example may be such a value, 
which changes as the operator moves the dark-back- 
ground selection bar vertically through the ten entries 
visible in the list, or operates the scroll bar to move other 
entries into view, or both. 

[0177] Up-to-date information for reaching the cus- 
tomer by phone, e-mail, or physical shipment may also 
be picked up by link into the customer's site, for use by 
the shop in quickly contacting the customer — as seen 
from the cluster of controls under the heading "CUS- 
TOMER" at left. Replacing such data, however, with in- 
formation for specific contact personnel at the custom- 
er's facilities is possible too, and represented by the 
"change" buttons in the same region of the screen. 

(Analogous "change" controls at the right end of 
the screen are for actually revising the printshop's own 
site, as telephone and mail contact data change. These 
are available to the customer by links to the printshop 
site in the GUI [Fig. 12] as seen by the customer.) 
[0178] The operator at the shop next scans the listing 
for the project whose proofing file is ready. The customer 
or the printshop may already have entered the project 
at hand into the RHCPS system; if not, the operator at 
the shop clicks the "File" menu item at top left, to obtain 
a generally conventional drop-down menu (not shown) 
that includes an entry "New" for creating a new entry for 
the project. Creation of a new job entry typically requires 
initial entry of some basic facts about the job. 
[0179] There is another entirely different way for the 
shop operator to get to the job at hand, within the RH- 
CPS system — namely, to type-in the printing house's 
own internal job-ticket number, which the operator 
knows. This can be done by entering the number directly 
into Fig. 3 — or, in event it is preferred by the system 
designer not to include that data-entry block in the 
mode-selection screen — then instead moving from 
Fig. 5, for selection of job-number finding mode, to Fig. 
6 for scrolling to the specified number. 

(Throughout almost ail of this document, the 
phrase "job ticket" refers to a strictly standardized doc- 
ument and computer file known as "JDF or "job defini- 
tion format". At this particular point in the discussion, 
however, particularly with reference to the illustrations 
mentioned above, two different kinds of job tickets are 
under discussion at the same time: here [1] the phrase 
"job ticket" without more refers to the printshop's con- 
ventional injemal job ticket, whereas [2] "JDF" refers to 
the strictly standardized document with its computer file. 
The JDF is the only kind of job ticket whose use is fully 
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integrated into the RHCPS — but for purposes of mesh- 
ing with the internal systems of many and probably most 
printing houses, it is necessary to deal, in the same 
breath, with the simple, traditional paper job ticket, and 
its nomenclature "job ticket". Ideally, where the print- 
shop's internal procedures can stand the change, those 
procedures are revised so that the JDF is the only job 
ticket used for any job that is in the RHCPS, and thus 
the JDF number is the only job-ticket number for those 
jobs.) 

[0180] An operator may know the job-ticket number 
because, for instance, the operator is holding a paper 
job ticket in hand. Alternatively a colleague may have 
just finished the proofing-file preparation and asked the 
operator to take the project to the next stage. 
[0181] As will be seen, the job-ticket number may be 
known to the RHCPS interface intrinsically through as- 
sociation with the service's own JDF entries; or may be 
picked up from the shop's site when needed. The oper- 
ator, however, alternatively can search by (Fig. 3) JDF 
number or date. (The system can be configured to use 
the date of entry into the system, or instead the deadline 
date.) 

[0182] For preferred embodiments of the invention 
the parameters displayed in the mode-selection screen 
(Fig. 3) are themselves determined by the commercial 
environment surrounding the job. If the printshop does 
business with parties other than primary customers, 
then presumably the shop operator may find it easier to 
search for some jobs by the names of those other parties 
— brokers, proofers, network couriers etc. In such a 
printshop advantageously the list of possible search 
modes in the mode-selection screen includes additional 
choices (e. g. Fig. 13B). 

[0183] If desired for comparative or other purposes, 
the operator at the shop may elect to display not only 
current, open projects but also earlier, now-closed jobs 
of the subject customer (Fig. 7). More commonly, to fo- 
cus quickly on needed information for a task at hand, 
the operator elects to exclude those from the displayed 
list — when the operator's chore is simply to send a cur- 
rent proof to the customer. If preferred, the designers 
may also provide the operator yet another display alter- 
native, namely that of listing closed jobs only (not 
shown). 

[0184] Once the shop's operator has an entry on- 
screen for the project, the operator verifies that this entry 
includes the already prepared proofing file. Then the op- 
erator may click on an icon or button (advantageously 
in the "details/edit" screen, not shown) to transmit that 
file through (for the present example) the Internet — in- 
cluding necessary color characterizations based on the 
production printer and any custom inking etc. that will 
be used. 

[0185] A related way for the proof to be expedited 
along its path is forthe proof-generating equipment (Fig. 
8), or operator (Fig. 9), to place the file in a so-called 
"hot folder" — a known phenomenon in the remote- 



proofing field, and in other related computer fields ( e. g. 
FAXing software) as well. This can be an entirely auto- 
matic operation triggered by completion of the preced- 
ing step, or can be a drag-and-drop operation performed 
5 by the operator; or can be both of these, e. g. with an 
operator confirming (Fig. 10) the step initiated by com- 
pletion of the previous equipment operation. (For this 
last-mentioned case if desired the system designers can 
include another choice, namely "Remove from hot fold- 
to er" — with suitable new status commands on the same 
or a following screen.) 

[0186] The system is programmed to monitor the hot 
folder and send whatever file is found in it. The trans- 
mission path is preset when the arrangements between 

15 the customer and printshop are established at the out- 
set, with other parameters of the job. 
[0187] At the customer's facility the file may be re- 
ceived automatically or on demand. Depending on the 
specific Internet access provisions (e. g. DSL line or 56k 

20 modem) in use — and operating options or settings se- 
lected — at the customer's facility, the customer's RH- 
CPS terminal (1) may simply acquire the proofing file, 
or (2) may acquire only a notification that the proofing 
file is available for downloading, or (3) may acquire noth- 

25 ing unless an operator of the customer's staff logs on to 
the RHCPS system, via the 'Net, and checks for incom- 
ing documents. 

[0188] In some of these cases, if the customer patron- 
izes more than one printing shop the customer's oper- 

30 ator may be called upon to locate the job that corre- 
sponds to the incoming proof — a procedure analogous ~ 
to that described above for the printshop operator in 
finding an entry in the system for the then-outgoing 
proof. If this step is required, the customer's operator 

35 eventually notes from the RHCPS interface a list of print- 
ing houses which that particular customer uses. 
[0189] If the customer uses more than one printshop, 
then, in a procedure like that already pursued at the 
printshop, the customer selects or types-in the name of 

40 the shop (Fig. 11 ). As the RHCPS design variants at this 
point are directly analogous to those previously de- 
scribed at length for the printshop operator, pictures of 
the corresponding screen views that follow are omitted 
here. 

45 [0190] If the customer uses only one printer then the 
system simply bypasses the printshop-selection step. In 
any event the RHCPS interface displays (Fig. 12) all the 
customer's jobs with the particular identified printing 
shop. (From this it will be understood that the customer's 

50 operator can log on to the system to see whether any 
proof file is waiting, even when no such file is waiting — 
and naturally will find that there is no proof to be printed 
just then.) 

[0191] This operator selects, from the displayed list, 
55 a desired job that has a proofing file waiting — and by 
operations at the GUI (advantageously through the as- 
sociated "details/edit" screen, not shown) queues that 
job to the proofing printer device. For fullest realization 
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of the RHCPS objectives, that printer device is one of 
the model line which provides dosed-loop color func- 
tions — particularly including the ability to print, read 
and interpret a color-calibration test pattern. 
[0192J Alternatively the proofing printer device too 5 
may operate on a hot-folder principle. In this case any 
proofing file that is downloaded, even automatically, 
from an authorized entity — as in this exemplary case 
the printing house — proceeds to the printer device, 
preferably, or at least to the printer- device queue. 10 
[0193] The printer device may also have the capability 
to scan and interpret color data for particular selected 
regions of the image area within an actual proof to be 
printed, as distinguished from a calibration pattern. 
These two kinds of information have their own respec- is 
tive advantages for various kinds of printing jobs and 
situations. 

[01 94] A key characteristic of preferred embodiments 
of the RHCPS is that the proofing printer device auto- 
matically transmits back to the printshop , in a different 20 
location from the printer device — Le. not only provides 
to the proofing operator at the customer's own facility 
— a report of the pseudocolorimetry operations just de- 
scribed. Thus all parties to the core technical transaction 
which constitutes "showing proof" can satisfy them- 25 
selves that what the customer is seeing is truly repre- 
sentative of what the final product (not yet produced) will 
be — or, in the alternative, can know for themselves in 
just what ways the proof appearance diverges from a 
truly representative image. 30 
[0195] If the customer finds that what the proof shows 
is not acceptable — in particular in terms of color — 
then the customer may simply send back a notification 
to that effect, through the RHCPS user interface as be- 
fore: or may instead, or in addition, communicate with 35 
the printshop by phone, e-mail etc. to help pinpoint the 
objection. The parties usually consult the closed-loop- 
color technical data to determine whether perhaps the 
problem may actually be only one of inaccuracy in ren- 
dering at the proof press. *o 
[0196] If not, then the printshop usually tries to correct 
the color in the data file from which it intends to print; 
and iterates the proofing and review process until the 
customer is satisfied with the representation of the final 
product-to-be. Advantageously the operator initiates all *5 
of these detailed steps by using controls in one of the 
"edit/details" screens (not shown), where all of the rele- 
vant image technical data are assembled and directly 
seen — and where there is no question which image or 
which job is under consideration. 50 
[01 97] As before, the data in such screens are assem- 
bled by links into both participants' sites as well as the 
RHCPS database — particularly including the site that 
is remote from the user at each end of the proofing re- 
spectively. Preferred embodiments of the invention thus 55 
make the most of both the business and the technical 
aspects of linking from the RHCPS user interface into 
the vendor's site, and possibly the vendor's user inter- 



face. As will be seen, however, these interiinkings are 
particularly striking and beneficial for transactions in- 
volving one or more additional participants. 
[0198] The foregoing chronology has been made 
rather complete as to not only the contribution of the GUI 
to the communication process but also several details 
of the interaction between the customer and the shop 
— so that it can be seen clearly how the GUI fits into or 
in some ways simulates parts of the classical interaction 
between these parties. This level of detail has been pre- 
sented here because this example is perhaps the sim- 
plest commercial situation which the RHCPS imple- 
ments. Many of these details are the same in the more- 
complex commercial situations described below, and so 
will be omitted from descriptions of those situations, 
which now follow. 

(b) Primary customer via a proofing ASP, to the 
printshop — This case encompasses several vari- 
ants or subcases. The customer may use the proof- 
ing ASP for only some jobs, or for all; the customer 
may use only one such ASP exclusively — or may 
use one for certain jobs and one or more other such 
ASPs for other jobs. 

[01 99] The customer may use the ASP to make all the 
arrangements with a printshop; or instead may use the 
ASP only for soft proofing and nothing else. Still again, 
the customer may use the service ASP as an interme- 
diary to the RHCPS, for all the functions of the RHCPS. 
(Although a customer in purest principle needs no inter- 
mediary to the RHCPS, this last option may be beneficial 
to a customer that is not adept in the workings of the 
printing industry and seeks a more-gentle buffer to the 
production people.) 

[0200] The customer may use other types of ASPs for 
some projects, or for all; or may never use other types 
of ASPs. The customer may either use or elect not to 
use traditional outside consultants or service entities 
such as graphic artists, advertising agencies, and cou- 
riers. 

[0201] To consider fully and separately each of the 
possible combinations of these several arrangements 
would be bewildering, and also unnecessary as the ba- 
sic principles are straightforwardly extended from a de- 
scription of just one or two ASPs. Therefore, with the 
basic operation in mind as described in subsection (a) 
above, only the more-significant departures from that 
basic operation are noted here. 
[0202] The user interface established by the RHCPS 
has a link to that established by the proofing ASP — 
and thereby to data on the ASP's site ( i. e. computer or 
computers). There may be a semantic question whether 
the link is to (1) the ASP's interface , or (2) the ASP's 
site, or (3) the ASP's computer system . To avoid debates 
over any such question, for purposes of this document 
those three concepts shall be considered synonymous. 
[0203] In preferred embodiments of the invention the 
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link is not merely a common hyperlink that leads (when 
"clicked") to the ASP's site, but rather is a graphical 
modification of the RHCPS interface itself, which selec- 
tively incorporates certain data, and graphical elements 
if desired, and related functions of the ASP into opera- 
tion of the remote hardcopy service's GUI. 
[0204] The first manifestation of expanded participa- 
tion when an ASP is involved appears when the print- 
shop's or customer's operator wishes to locate data for 
a job at hand. Once again it is necessary to begin by 
deciding how to search — and now there is another op- 
tion not encountered before, namely to search by proof- 
ing ASP (rather than by customer, job number etc.). 
[0205] Behind this option is a difference in the char- 
acter and number of links from the RHCPS site to sites 
of the customer, printing house, and ASP. In accordance 
with preferred embodiments of the invention, links to an 
ASP are now incorporated where before only the RH- 
CPS, customer and printshop were interlinked. 
[0206] The degree of apparent integration into the 
structure of the GUI is advantageously chosen by the 
system designers. The selection of job-search mode 
may give the different modes the appearance of data , 
presented in data windows (Fig. 13A); or the appear- 
ance of a part of the virtual control panel flat labeling , 
selected by marking within radio buttons (Fig. 13B); or 
the appearance of a part of the virtual controls, selected 
by clicking virtual raised pushbuttons (Fig. 1 3C). Similar 
and other choices are made with regard to the degree 
of integration suggested in screens (Figs. 14A through 
1 5) for selecting customer, printshop or ASP, after mode 
selection is complete. 

[0207] It will be understood that in reality all of these 
modes are equally structural — namely, not structural 
at all but only a matter of different graphics. The different 
graphics styles nevertheless are important in that they 
convey to operators of the system some conceptualiza- 
tion of the business relationships among the RHCPS op- 
erator, the ASP and even the customer. 
[0208] Where an ordinary Worldwide-Web URL nota- 
tion is used for a link (Fig. 14A), most Web-wise users 
will receive a connotation of little or no proprietary con- 
nection between parties. It suggests little more than a 
courtesy referral. A data-window presentation (Fig. 1 4B) 
may instead possibly suggest that the parties' relation- 
ship is in the nature of arm's-length service by the RH- 
CPS to the other participants: the RHCPS recognizes 
the parties but treats their data, their identities, and even 
their functions as essentially fungible. 
[0209] A radio-button or check-box presentation (Fig. 
. 14C), with the parties' identities and even their types (e. 
g. "proof er") appearing as part of flat-panel labeling, 
probably connotes strongly to many GUI users that the 
parties have at least some sort of mutual cooperative 
agreement. Presenting the identities or even their types 
at the faces of virtual raised pushbuttons (Figs. 14D and 
1 5) can suggest to observant users that the parties may 
be engaged in a copartnering or coventuring form of en- 



terprise. 

[0210] Thus — now extending the customer/print- 
shop example of subsection (a) above — when either 
the customer's or the printshop's operator brings up the 

5 opposite party's listing of transactions, a reference to the 
service ASP may appear in addition (Figs. 16 through 
1 7A), or instead. The specific situations, and the specific 
ways, in which this interception of transactions by the 
ASP, or interjection of the ASP into the printshop/cus- 

10 tomer workflow, depends intimately upon the specifics 
of the relationship between the customer and ASP. 
[0211] For example if the ASP is handling all proofing 
details for the client, then when the printshop's proofing 
file is ready — and the shop personnel log onto the RH- 

15 CPS to transmit the file — what will be displayed may 
at first be an identification not of the primary customer 
but rather of the service ASP. In the same transaction 
some functions unrelated to proofing as such may in- 
stead bypass the ASP and go directly to the primary, 

20 provided that the customer or ASP has set up the ac- 
count that way for the particular job. In that case, if the 
printshop attempts to brings up the ASP to arrange e. 
cj. delivery, then the GUI can reroute the shop staff to 
the customer directly. 

25 [0212] Examples of these sorts of shielding or diver- 
sion of contacts will be presented shortly in connection 
with broker-ASP arrangements. As to the proofing ASP 
under discussion here, however, no such guarded pres- 
entation appears. Thus Fig. 16 shows to the printshop 

30 operator, in an evenhanded way, all the information 
needed to contact the primary or the ASP. 
[0213] This interface leaves it to an operator's pre- 
knowledge of the participants, or otherwise to that op- 
erator's experience, intelligence and best instincts, to 

35 select the appropriate party for each kind of contact. 
Such selection may be e. g. technical people for techni- 
cal questions, business people for business questions, 
proofer for matters relating to proofing, and so forth. 
[0214] Fig. 1 7 conversely shows the customer all the 

40 information all that is needed to contact the printshop or 
the proofer. An interesting example of a hybrid setup ap- 
pears in the alternative form of Fig. 17A: here the RH- 
CPS has linked the customer through to the proofer's 
site including custom graphics that encourage the pri- 

45 mary to contact the proofer rather than the printing 
house — but do not actively constrain the primary to do 
so. The data portions of the interface are strictly drawn 
from the standard RHCPS setup. 
[0215] For showing proof, the GUI as seen at the print- 
so shop too may lead the shop staff to transmit to the proof- 
ing ASP — whether the particular proof is to be a soft/ 
virtual proof for viewing on-screen, or a hardcopy proof. 
(Here, however, the ASP has perhaps wisely chosen not 
to approach the shop operator with a conspicuously 

55 marketingoriented style, rather hewing to a just-busi- 
ness-betweentradesmen sort of presentation.) The 
proofing ASP, most commonly close to the primary cus- 
tomer geographically, is then responsible for contacting 
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the customer to arrange for actual viewing of the proof. 
[0216] In the hardcopy case, that contact generally 
entails arranging a physical movement of printed docu- 
ment to customer or of the customer to the ASP's facil- 
ity. The ASP operators can take the opportunity to check s 
the proof themselves, preliminarily, if they in fact see 
part of their function as providing the "butter" suggested 
earlier. 

[0217] In this case the ASP may choose to advise the 
primary how best to deal with irregularities in the proof 10 

— what the options and associated cost/benefit rela- 
tionships are, etc. Alternatively the ASP may instead un- 
dertake, on its own responsibility, to reject or even to 
accept the proof, if that reasonably appears to be within 

the scope of the understanding between primary and *5 
ASP. 

(Such understanding is probably best reduced to 
writing, but such writing may be conveyed and approved 
through the same electronic systems as other portions 
of the communications. In any event, such contractual 20 
specifics are outside the scope of this document.) 
[021 8] Fig. 1 8, the view as seen by the proofer J s op- 
erator, reverts to fully standardized form. These four 
views thus represent a relatively low-key, open and 
trusting set of relationships, and this is one very popular 25 
business style in the trade. 

[0219] As these views suggest, if the ASP elects to 
use the RHCPS service for part of its communications 
with the primary customer, then the primary can either 
be set up to see the RHCPS interface or — if one exists 30 

— the ASP's own interface. If the arrangement is the 
former, Lje. if the customer is to see the RHCPS inter- 
face, then in effect the ASP and the customer are oper- 
ating in parallel; they both see some of the same lists 
and data from the RHCPS. 35 
[0220] On the RHCPS interface as seen on the cus- 
tomer's computer, however, what appears is the ASP in 
addition to the printshop — or instead of the printshop 

— again depending upon the arrangements made. In 
either event, the customer will see only its own jobs, not 40 
other customers' jobs, with the ASP and/or the print- 
shop. 

[0221] What appears on the ASP's computer (Fig. 18) 
in this case is either (1 ) the customer and the customer's 
jobs, if the ASP operator elects to call them up that way, « 
or (2) the printshop and the customer's jobs, if the ASP 
operator elects that approach. The same group of jobs 
is displayed in either event, provided that the ASP in fact 
elects to see that customer's jobs (as distinguished from 
checking on all its jobs with the same printshop). so 
[0222] If instead the customer is set up to see the 
ASP's user interface rather than the RHCPS's, then in 
preferred embodiments of the invention the customer 
will see its same jobs at the printshop — but only those 
being handled by this particular ASP Those data are 55 
passed through by the ASP's interface to the customer, 
but not necessarily with identification of the printshop. 
[0223] The latter issue is determined by the setup of 



the ASP's own interface, which in turn is configured 
based upon the ASP's preferred way of doing business. 
Some will operate on the philosophy that openness is 
an ideal basis for dealing with customers; others on the 
philosophy that the customer will sooner or later decide 
to eliminate the middleman and should not be tempted. 
[0224] Thus as noted earlier the RHCPS workflow- 
management component of the present invention ac- 
commodates many different business and interpersonal 
styles, and in many ways encourages divergent healthy 
forms of competition. What it does not do, in the example 
under discussion, is either force the ASP to be open 
when there is concern that this will lead to loss of busi- 
ness; or conversely force the ASP to be guarded when 
the ASP's philosophy is open — or when there is con- 
cern that, for instance, the customer will eventually per- 
ceive the guardedness and change vendors as a result. 
[0225] The workf low-management protocol is ex- 
tremely flexible and versatile. In particular the ASP is at 
liberty to follow the guarded philosophy with one cus- 
tomer — as for instance a customer who is regarded as 
volatile, or overly price conscious — but simultaneously 
to follow the open philosophy with another customer, as 
for instance one who seems inclined toward vendor loy- 
alty, or toward interpersonal criteria in selecting or main- 
taining vendors, or perhaps simply one who is too so- 
phisticated to be kept in the dark. The RHCPS interface 
options are set up as a tool whereby the ASP can im- 
plement its own philosophies as convolved with its as- 
sessment of individual customers. 
[0226] Although the array of these several variants 
may seem complex in discussion, as will be understood 
indication of the selections is very straightforward in 
terms of user-interface options. Once so entered, the 
RHCPS system continues to implement the agreed-up- 
on arrangements unless and until others are substitut- 
ed. 

(c) Primary customer via a network ASP to the proof 
ASP or printshop, or both — The variants of this 
case, in comparison with those taken up in the pre- 
ceding section, represent both a different function 
and another level of complexity. Functional contri- 
butions of a network or "transport*' ASP to comple- 
tion of projects that entail remote proofing is quali- 
tatively different from those of the proofing ASP 
considered in subsection (b) above; yet as will be 
seen the RHCPS workflow-management compo- 
nent readily accommodates the transport function 
as well as the proofing function. 

[0227] As to complexity, the involvement of a network/ 
transport ASP is not necessarily simply a substitute for 
the proofing ASP arrangements discussed above, but 
can instead be an overlay on the several variants of the 
proofing ASP. In other words, the commercial relation- 
ships are not limited to being linear or three cornered at 
most, but can involve four and five parties to the same 
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transaction. 

[0228] In fact the feasibility of using so many different 
specializing enterprises for the same job is strongly and 
distinctly enhanced, not obstructed, by preferred em- 
bodiments of the present invention. The workf low-man- 
aging module helps greatly in keeping all the partici- 
pants in step, informed, and ready to make their contri- 
butions at the right times without tripping over one an- 
other — as they might if all the arrangements had to be 
made by, for instance, FAXes and telephone calls. 
[0229] First as to the different function, again positing 
the basic situation of a printshop that has a proofing file 
ready for transmission, suppose first that there is a net- 
work ASP involved but no proofing ASP. The printshop 
then seeks to provide the file to the primary customer. 
[0230] The network ASP may be engaged either by 
the printshop or by the customer. Furthermore, if it is the 
shop that elects to use the private network it may do so 
either for all customers or for just the particular customer 
in question — or even for just certain jobs, or certain 
jobs of that customer. 

[0231] Conversely if it is the customer's election to 
use a network ASP, that may be for all printing work, or 
only for jobs with the particular printshop, or only for just 
certain jobs, or certain jobs with that printshop. In any 
event, when the printing-house operator is ready to send 
the proof to the customer, as with the proofing ASP the 
operator can log onto the RHCPS interface and locate 
the job either by customer or by ASP (in this case, prob- 
ably the ASP whose function is involved, namely the net- 
work provider). 

[0232] Also if preferred, the operator can identify the 
job by searching with some internal indicator (job ticket 
number, for instance) which the operator happens to 
know — just as in the linear or two-party case. Here as 
before, once the operator has called up the job on the 
remote-proofing interface the correct contact is invoked 
inherently by those same keystrokes. (Other options 
mentioned earlier, including a hot folder, are equally ap- 
plicable here.) 

[0233] The system, in other words, is ordinarily pre- 
configured, when the job is first set up, to transmit in 
some particular way specified at the outset as between 
the customer and the shop. Thus if a network ASP is to 
be used, then when the operator instructs the system to 
proceed with the transmission it is most commonly 
ready to do so by routing the file through that designated 
network. Most typically the necessary connections for 
the transmission are preset for that network. 
[0234] All of these choices are directly analogous to 
those illustrated earlier. Accordingly the illustrations 
(Figs. 3 through 6, 11, and 13A through 15) presented 
in the preceding subsections for job search shall be con- 
sidered to illustrate the present subject matter as well 
— the differences in screen appearance being only a 
matter of inserting a different participant type and iden- 
tity, manifesting the involvement of links to a different 
sort of participant. 



[0235] At the other end of the transmission, in this rel- 
atively simple case of printshop and primary customer 
working through a private network, from the perspective 
of the customer's operatorthe scene is again rather sim- 

5 pie. As before, that operator can receive, or watch for, 
or look up, its pending jobs by printshop, or by network 
ASP (unless that information is inhibited by arrange- 
ments with the printing house, as will be explained short- 
ly) — or once again by an RHCPS JDF job ticket 

10 number, or simply by the customer's own internal refer- 
ence number for the project, or a relevant date. 
[0236] In any of these events the customer operator 
is drawn quickly to the incoming proofing file. An alter- 
native arrangement, as mentioned in an earlier exam- 

15 pie, is along the model of a hot folder that sets up the 
job to run on the customer's proofing printer upon re- 
ceipt, without necessarily involving any operator action. 
[0237] This subsection focuses upon participation of 
the network ASP, and positive benefits flow from the 

20 present invention in this regard as well. More specifical- 
ly, when any question arises about the transmission, not 
only the primary-customer and the printing-house oper- 
ators but also an network-ASP technician readily gain 
access to all the identical particulars of the transmission. 

25 [0238] This means that precisely the data seen by the 
two operators about the transmission, as initiated from 
the printing house and into the ASP's own equipment, 
can be seen by the ASP technician. Usually the 
net-ASP's screen display is augmented with additional 

30 technical data developed at the point of launching the 
file into the network. 

[0239] In the absence of this RHCPS workflow con- 
trol, the scene is instead one that is nowadays very fa- 
miliar. An upset user telephones a harried technician, 
35 trying to describe something relatively nebulous that 
happened sometime earlier in the day, or perhaps the 
previous day. 

[0240] When instead two or all three concerned par- 
ties can quickly be looking at the same data, at the same 

40 time, the results are salutary in several ways. This com- 
monality of information among three parties to a trou- 
bleshooting conference contributes greatly to a valuable 
calming sense of orderliness and confidence, as well as 
to speediest possible actual resolution of any flaw in the 

45 transmission. This collaborative model is strikingly dif- 
ferent from an all-too-common scenario of the computer 
era — two vendors each telling a primary customer to 
check with the other vendor. 

[0241] These technological benefits, however, to a 
so certain extent are transcended by commercial advan- 
tages introduced earlier. Thus for example the printing- 
house operator may be concerned that in conversation 
with the customer the network ASP may give away too 
much information about competing printshops that also 
55 happen to use the net ASP; and in this case the work- 
flow-management service can be configured to mini- 
mize contact between customer and ASP. 
[0242] Even in attempting to resolve a transmission- 
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failure situation it is not strictly necessary to convene all 
three of the operators. Rather, if the printshop has a pol- 
icy of minimizing exposure of customers to use of the 
network ASP then ordinarily the problem can be prompt- 
ly resolved between the shop and the ASP. 
[0243] In such a situation the printshop elects to take 
on a slightly greater part of the burden of resolving the 
matter, in return for maintaining its more-guarded stance 
as to its supporting net ASP Even the use of the private 
network itself can be made particularly inconspicuous if 
that network serves primarily a leg of the connections 
which is between the printshop and the Internet. 
[0244] If desired, the RHCPS interface as seen at a 
customer's facility can be made to see only the printshop 
identification, and not the network ASP's at all. The 
net- ASP activities in effect then become a part of the 
printshop services. 

[0245] Of course the customer is always free to in- 
quire separately into the full character of the RHCPS or 
of the net ASP. In that event the customer can if desired 
establish, or reestablish as the case may be : a fuller con- 
trol of its own commerce. 

[0246] Now secondly, as stated at the beginning of 
this subsection (c) it is possible that the participants are 
not only three — the customer, shop, and net ASP — 
but also a proofing ASP such as discussed in the previ- 
ous subsection (b). Representative forms of the user in- 
terface forthese four-cornered situations appear in Figs. 
1 9 through 22 — here too the basic model being one 
that is relatively open, yet with room for fine adjust- 
ments. In this case once again the RHCPS workflow 
manager seamlessly integrates all these elements, 
sending the file to the right party (whether customer or 
proofing ASP, or both) and through the prearranged net- 
work. 

[0247] In this environment any failure of smooth op- 
erations would ordinarily — that is t in the absence of 
the RHCPS workflow component — be a source of ma- 
jor abrasion. It is a well-known irritant, in the computer 
age, that every participant seems to suggest some other 
participant as the root source of any failure. The greater 
the number of parties involved, the more frustrating and 
even exasperating this phenomenon can be. 
[0248] The RHCPS, however, instead enables effi- 
cient resolution of service interruptions on a participative 
basis, in even a four- or five-cornered transaction, where 
the participants are operating in a relatively open under- 
standing about the relationships among the several 
services. At the same time preferred embodiments of 
the RHCPS can accommodate other forms of under- 
standing — e. g. they may permit some of the vendors 
involved to shoulder some added fraction of effort re- 
quired to keep operations running smoothly, in return for 
the ability to partly isolate customers from other opera- 
tors in the trade. 

[0249] Although the desire to work openly or guard- 
edly has been discussed above in relation to printshops, 
other parties may wish to exercise such options. Pref- 



erences of this sort may be felt by ASPs and even by 
customers — for reasons of simply wishing to control 
their own costs, or business confidences, or operating 
image; or whatever personal reasons may arise. 

5 [0250] In these ways the RHCPS resolves many of 
the business tensions discussed in the "BACK- 
GROUND" section of this document. It thereby pro- 
motes and enhances competition of an economically 
healthy kind, and minimizes the problems set forth in 

10 that earlier section. 

(d) Primary customer via a transaction ASP to other 
parties — Here too, this transASP may be in a rel- 
atively simple direct business relation between the 
is primary and the printshop, with no other ASPs in- 
volved; or this ASP's relationship may be only one 
of several. That is, in addition to the middleman ASP 
there may also be any of the previously described 
relationships with ASPs for proofing or for data 
20 transmission, or both. 

[0251] The general principles for preferred embodi- 
ments of the invention here, however, are analogous to 
those discussed above. In view of the relatively exten- 
ds sive earlier discussions, these general principles are on- 
ly summarized here: the RHCPS interface, as before 
preferably though not necessarily a graphical type, 
gives each user log-in options custom-established for 
that specific user — and based upon several factors. 
30 [0252] Factors include (1) all entities that are party to 
the particular transaction of interest; and (2) preferences 
of the entity that initiates the RHCPS arrangements for 
the particular transaction — sometimes subject to un- 
derstandings with some other entity or entities, as noted 
35 earlier. In particular, usually log-in and other operating 
options are set up as a so-called "default" (in the com- 
puter-jargon sense, not the financial sense). 
[0253] The default settings are usually subject to 
override by the user or users who are — or who are 
positioned in the chain of commerce relatively closer to 
— the primary customer. Although the primary custom- 
er, and those in position to act on the primary's behalf, 
thus most commonly have authority to override the de- 
fault arrangements, the full extent of such options may 
45 not always be clear to parties that have them. 

[0254] Of all the parties that may purposely leave 
such options incompletely explained, transaction or bro- 
ker ASPs are perhaps the most prominent. This may be 
a natural and understandable result of the nature of such 
50 businesses, in view of the following considerations. 
[0255] As most transASPs do not participate directly 
in physical creation of the final product, the primary eco- 
nomic reward for their activity cannot be linked to any 
esthetic or mechanical function. Rather they provide 
55 convenience, and familiarity with trade practice, and ide- 
ally sound guidance of the primary customer to a printing 
house and other vendors that are optimum for the nature 
of the project. 
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[0256] These functions — although real, and poten- 
tially of extremely great value — are hard to quantify, 
and may be difficult for some primary customers to ap- 
preciate at all. Vulnerability to diversion of clientele 
therefore may be greatest for the trans ASP, of all the 
participants in these transactions. 
[0257] Representative versions of a GUI for bro- 
ker-ASP situations appear in Figs. 23 through 27. In the 
example here, only the broker (transASP) has full view 
(Fig. 27) of all details and data. 
[0258] At the opposite extreme is the sharply restrict- 
ed visibility of the primary customer, who in this example 
sees (Fig. 24) only two ASPs — the broker and the 
proof er. The proofed business contact line in the upper, 
data-window screen section is removed entirely — ob- 
scuring absence of the contact's name — as are the 
"business" radio-button legends for both e-mail and 
shipping label. Additional screen titles within the frame 
appear automatically, adjusting to the absence of infor- 
mation in two columns — which as shown can be kept 
in their usual positions if desired to minimize confusion 
between different participating operators. 
[0259] Between these two poles of relative visibility 
are some intermediate information-access levels. Thus 
in the printshop operator's screen (Fig. 23) the names 
of all contacts at the primary customer's facility are un- 
listed, the phone and e-mail controls for contacting that 
facility are grayed out, and the GUI reveals only the cus- 
tomer's project reference number, and address data for 
a mailing label — so that finished magazines can be 
shipped to the customer. 

[0260] A like level of information access is accorded 
to the network ASP (Fig. 26), who it is presumed may 
have to ship some piece of network equipment to the 
primary customer, or even service such an item at that 
customer's facility. Contours of information access are 
formed in yet another way for the proofing ASP (Fig. 25), 
who is enabled to consult with the primary customer's 
artistic or technical people — but not with management: 
the proscribed contact's name is unlisted in the "CUS- 
TOMER" column, and the phone and e-mail "business" 
options are grayed out. 

[0261 ] This example is constructed to include another 
ASP, in the column headed "PREPRESS/SPECIAL" — 
e. g. a trade prepress house, or other special-purpose 
vendor. (In the event that both a prepress firm and an- 
other special vendor are present, either condensed [nar- 
row] fonts can be used to permit displaying all partici- 
pants within the width of the screen or as noted earlier 
suitable horizontal-scroll capability can be provided for 
the upper portion of the screen.) 
[0262] The prepress house is functionally closest to 
the printshop and proofer. Prepress therefore might log- 
ically receive e. g. access to both those entities — plus 
the same need-to-know customer artistic/technical ac- 
cess as the proofer. 

[0263] As shown , the system primarily directs the cus- 
tomer to the broker ASP, who in effect becomes sym- 



bolic of the customer's overall project or projects. From 
the customer's perspective, in effect the sole vendor in- 
volved is the broker. 

[0264] In the most-high ly preferred embodiments of 

5 the invention, as noted earlier the primary customer has 
the option of overriding all such arrangements. This op- 
tion is enabled — but not encouraged, and certainly 
never pushed on the customer — by making available 
to the primary customer information about the option. 

10 [0265] The information is ideally included in an RH- 
CPS user interface seen by the primary customer. This 
can be done in the form of an external link to the con- 
tractual terms of the RHCPS, which include the informa- 
tion about the option; or in the form of an internal "help" 

is screen that includes the terms. 

[0266] In implementing either of these arrangements, 
careful attention must be given to the wording and 
graphics used in leading to and presenting the custom- 
er's override option. It is a sensitive point and best 

20 worked out among specialists in law, marketing, cus- 
tomer relations, and professional editing. 
[0267] The extent to which the link and terms are con- 
spicuous, in the RHCPS user interface, is important. 
The basic mechanics may encompass use of the "Help" 

25 menu item that appears in the many tabulation screens 
shown in the accompanying drawings. 
[0268] As one presentational technique, words such 
as "RHCPS contract terms" simply may be included in 
the drop-down submenu that appears when that main 

30 menu item is clicked. This may seem overly conspicu- 
ous, but it should be borne in mind that the terms them- 
selves are typically lengthy, including many more claus- 
es than just the user-override option that is under dis- 
cussion here. 

35 [0269] Another technique is to respond to a user's 
click on the "Help" item in the main menu by opening an 
intermediate selection dialog box (not shown) that con- 
tains a button or link to invoke the contract terms (in- 
stead of moving along to the main help screens). Alter- 

40 natively such a button or link can be incorporated direct- 
ly into a main help screen itself (Fig. 28). Depending on 
the layout and wording in such an intermediate help di- 
alog or main help screen, the impact of the contract- 
terms availability may be either strengthened or weak- 

45 ened, relative to putting it into the help menu as first sug- 
gested above. 

[0270] In either event, the placement of the override 
option within the terms, and the nature of the wording 
used as a title for it, are extremely variable. This varia- 
50 bility still leaves room for further fine tuning of the con- 
tent and tone of the presentation. 

5. INTEGRATION WITH A SOFT-PROOFING A. S. P. 

55 [0271] To facilitate some aspects of the invention, ad- 
vantageously some features are implemented within 
printer-device systems, and complementary features 
appear in the remote soft-proofing ASP. Although these 
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implementations may not be strictly necessary, the re- 
sult is an optimization of the invention that also optimiz- 
es integration between the remote soft-proofing ASP 
and the remote hardcopy proofing service. 
[0272] The new printer-device systems will be char- 
acterized here as "remote-proof enabled" or "RP-ena- 
bled". They include a printing device with front-end soft- 
ware. 

[0273] These features make it realistic for users to 
trust the integrated service, basically by ensuring output 
consistency of hardcopy proofs — l^., by providing for 
consistent printing (same contents, layout, color etc.) on 
any remote-proof printer of the line. The features also 
facilitate the remote-proofing workflow. 

(a) PDF plus JDF as a basis for workflow — To en- 
sure output consistency, it is very helpful to provide 
that: 

■ all the information required to correctly print a 
proof is included in the data sent from the proof 
originator to the proof receiver; and 

■ the setups used both on the originating and re- 
ceiving printers to print the proofs are consist- 
ent. 

These requirements are achieved by using a com- 
bination of PDF (Adobe "portable document file") 
and JDF ("Job Definition File") to carry all the re- 
quired information, as follows. 

■Contents of the proof itself are carried in the PDF. 
This file preferably meets very strict requirements 
in terms of the information included — L_e. , for ideal 
results it includes all the color, relevant information, 
fonts and images. 

■ The JDF job ticket stores all the information on 
how the proof has to be printed to ensure a consist- 
ent output. It can also store the information on sta- 
tus of the remote proofing workflow for the specific 
proof. 

[0274] The RP -enabled printer systems include the 
tools required to create the PDF and JDF parts of a re- 
mote proof. These tools are fully integrated into the 
front-end software (for example in a raster image proc- 
essor that is in or associated with the printer), so that a 
user can easily create a proof to be sent to a remote 
user — and not only send it but also print it in the user's 
local printer. 

[0275] On the receiver side, before printing a remote 
proof some checking is performed. This ensures that the 
proof data meet the requirements to ensure output con- 
sistency. 

(b) Managed and calibrated color system — Use of 



the automatic color calibration and the color-man- 
agement features in the printer ensures that the 
color behavior of RP-enabled printers is consistent. 
This means that any proof which contains the cor- 
5 rect color information can be printed consistently, in 
terms of color, in any RP-enabled printer or at least 
any such printer of the product line. 

[0276] Both the automatic color calibration and color- 
10 management features are implemented by interaction 
of the printer device and the front-end software. 

(c) Proof checking and feedback — The RP-ena- 
bled printer systems has the ability to check for suc- 

15 cessful and correct printing of a hardcopy proof, and 
its quality as well. This information can be made 
available to the user who printed the proof, and also 
sent back through the RHCPS to the proof origina- 
tor (e. g. the user who originated the proof) so that 

20 the originator can know when the proof was printed 
and what the quality of that proof was. 

[0277] Thus the entire RHCPS operates on a closed- 
loop basis. In this way the system is made very trustable , 

25 thus resolving one of the major inadequacies of the art. 
[0278] The proof-checking functionality advanta- 
geously uses the same hardware in the printer that is 
used in automatic color calibration. The entire proce- 
dure (proof checking and status feedback) is integrated 

30 into the front-end software so that it can be triggered 
automatically — and can be transparent to the user, de- 
pending on the settings of the RHCPS or the proof itself, 
or both. 

35 (d) Obligations imposed on the remote soft-proofing 
ASP — To enable the RHCPS to make full use of 
the RP-enabling features integrated into the printer 
system, several provisions should be made by the 
soft-proof ASP: 

40 

■ support PDF-plus-JDF workflow — The soft- 
proof ASP should be able to transfer the proof 
data from the sender to the receiver. Ideally the 
ASP should also use the JDF job ticket to store 

^5 essentially all information related to its own 

services — for example the originator and in- 
tended receiver(s), and the status of the proof 
— so that the JDF ticket is the only job ticket 
used. 

50 

■ integration of the proof-gene rating tools and 
the soft-proof ASP — As described above, 
proof -generating tools are integrated into the 
printer front-end software. There should be 

55 some way to pass proof data, once generated, 

to the soft-proofing ASP. For this purpose the 
ASP can provide a hot folder (discussed earlier) 
or equivalent arrangement. 
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■ integration of the proof-consuming tools and 
the soft-proof ASP — When proofing data are 
received through the soft-proofing ASP, the da- 
ta should be passed to the printer front end for 
processing and printing. Again, this calls for a 
hot folder or other feature — most typically a 
feature of the user interface, graphical or oth- 
erwise. 

■ support status feedback — The printer front 
end triggers automatic checking of the proof, 
once printed, and generation of information on 
the printing result. There should be a way to 
send this information from the front end to the 
soft-proof ASP so that it can be forwarded to 
the proof originator. 

■ support user-collaboration features — The 
ASP should make provision for the proof receiv- 
er to add comments, l_e. annotations, and pref- 
erably to approve the proof in writing after hav- 
ing printed it. All such information should be ac- 
cessible to the proof originator. 

These may be considered basic obligations of the 
ASP, although people skilled in this field will appre- 
ciate that a reduced level of functionality and serv- 
ice may yet be obtained in the absence of some 
such provisions. In addition to these basic features, 
some additional provisions improve workflow and 
usability: 

■ proof data checking — To ensure output con- 
sistency, ideally a check is always performed at 
the receiver side before the proof is printed. To 
save time and bandwidth, however, it is useful 
that either the ASP or RHCPS itself — depend- 
ing on the circumstances — also prevalidate 
the data before downloading by the receiver. 

■ hosting proof-generation tools by the ASP — 
Since the RP-enabled printer systems integrate 
the tools for generating correct proofing data, 
any user with such a printer can generate re- 
mote proofs. In some cases, however, it is also 
useful to have the ability to run those tools on 
the ASP's system — thereby enabling collab- 
oration by ASP subscribers who have no such 
printer. 

■ integration of soft and hardcopy proofing — 
Some soft-proofing ASPs may themselves use 
a commercial service, such as ReafTime- 
Proof 1 ™ service, for soft proofing. That service 
allows soft proofing of several types of files. 

[0279] In order to integrate it with the RHCPS, the 
soft-proofing application ( i. e. the ASP) should be able 



to: 

(i) send data to the RHCPS that satisfies the obli- 
gations outlined above (PDF-plus-JDF, containing 

5 all the color characterization, fonts, and so on); and 

(ii) process RHCPS proofs and use the embedded 
color-characterization data (color profiles in the 
PDF file, etc.) 

io [0280] The first of these can be accomplished by in- 
tegrating into the ASP software at least a part of the 
proof-generation tools of the present invention, e. g. a 
software kernel. 

15 ( e ) Integration between the ASP and RHCPS — 
The present invention encompasses a service that 
can be offered by a sponsoring company — to con- 
sider an example in point, the Hewlett Packard 
Company The service is made available, possibly 

20 for a fee, to users who register their RP-enabled 
printer systems in that sponsor's customer-registra- 
tion system. 

[0281] The RHCPS is a basic service that itself pro- 
25 vides remote hardcopy proofing only. A user desiring 
other services than that — e. g. high-bandwidth trans- 
mission, file storage (so-called "digital asset manage- 
ment") or soft proofing — should engage one or more 
ASPs to obtain those services. 
30 [0282] To facilitate an upgrade path to such ASP serv- 
ices, as well as interaction between customers of the 
RHCPS and ASP respectively, preferably these fea- 
tures are included: 

35 ■ As indicated at some length in previous sections of 
this document, the RHCPS customer database is 
able to identify the users who have decided to be 
customers of, e. g. , a soft -proofing ASP. Proofs sent 
to or from one of these users through the RHCPS 

40 are redirected to the ASP, through the agency of the 
many interface features previously detailed. 

■ The database also advantageously enables each 
user to search for other registered users, of any 

45 type, including both potential vendors and custom- 
ers — except for registrants who elect privacy, Le. 
elect to opt out of such tabulation. 

■ The RHCPS and the soft-proofing ASP each allow 
so specifying, as a proof receiver, a user that is on the 

other service. For example, a remote-proof origina- 
tor who is using a soft-proof ASP can specify that 
the receiver is using the RHCPS — and in this case 
the proof is forwarded from the ASP to the RHCPS. 

55 

m Accordingly a protocol is included for forwarding 
proofs between the two services. This protocol is 
advantageously bidirectional so that that receiving 
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service can return to the originator various kinds of 
information such as error data, closed-loop proofing 
feedback. The protocol is a standard one and can 
be used to expand the integration — between the 
two companies, to include other services of theirs 
— and also to encompass ASPs of other types as 
discussed earlier. 

[0283] AM such integration can be accomplished 
through the Internet or by more-direct backbone con- 
nection as preferred. Generally integration is facilitated 
thus: 

■ The RHCPS maintains a full user database for all 
participating ASPs as well as its own. 

■ A data field flags each respective ASP's subset of 
these users. These can overlap, since customers 
are at liberty to engage multiple ASPs of different 
types and even of the same type for different jobs. 

■ The RHC PS tests that data field on receipt of a proof 
for transmission to a user. 

* ■ These arrangements are regarded as nominally re- 
ciprocal — each ASP is expected, though not re- 
quired, to do the same. 

■ Both exclusive and nonexclusive forms of these ar- 
rangements are encompassed within the invention 
as defined in certain of the appended claims, and 
may be regarded as species of the invention. Ex- 
clusivity is thus a matter of business preference and 
business arrangements between the participants. 

[0284] In these ways, as earlier pointed out, the RH- 
CPS expands the capabilities of the soft-proofing ASP 

— which already has a useful service. The RHCPS 
does not obsolete that service, which continues to be 
particularly viable for highest speed, for concept proof- 
ing, and for preliminary proofing. Thus the RHCPS of 
the present invention does not compete with so much 
as mutually complement the soft-proofing ASP. 

6. INTEGRATION WITH A TRANSACTION A. S. P. 

[0285] As described earlier, a transaction or buyer 
ASP focuses on management of a job, and order data 

— and the integration of order processing and status 
tracking with various functions managed by a printshop. 
Typically this type of ASP provides very little support 
(representatively perhaps just an FTP server) to the 
sharing of content files between a buyer and a printer, 
or digital asset management. It usually imposes no re- 
striction on the contents shared, and provides no tool 
for proof generation or related functions. 

[0286] One representative trans ASP offers custom- 
ized and branded websites for both buyers and printers, 



with ongoing management and support. The firm does 
not have a general standard website design. 
[0287] This sort of enterprise concerns itself with 
management of the electronic commerce between buy- 
5 er and printer, particularly job specification and status 
tracking. Such operation is well complemented by the 
RHCPS of the present invention or, alternatively, by an- 
other service ASP such as a soft p roofer or private net- 
work. 

w [0288] The transASP sets up websites for both the 
buyer and printer, and directs the two to each other 
through a protocol. Thereafter the ASP continues as a 
sort of arm's-length printing broker or facilitator 

'5 (a) Workflow — Integration of a transASP with an 
RHCPS, according to the present invention, pro- 
duces workflow generally as described below. 

■ When creating a project, the buyer specifies (by 
20 a computer-interface checkbox or the like) that 

remote proofing should be used on the project 
or at least certain components. If the buyer is 
using the printer's site to specify the job, the re- 
mote-proofing proof type appears only if the 
25 printer has remote-proofing capabilities. 

[0289] The converse is also true: if the buyer is using 
the buyer's own site to specify the job, the "remote proof- 
ing" option will only appear if the buyer has remote- 
st? proofing capabilities. The main difference is that, in this 
case, the remote proofing capabilities of the printer 
could be used as selection criteria. That is, only printers 
that can generate remote proofs would be able to bid for 
that job when an RFQ is promulgated. 
35 [0290] In any case, there is preferably a link from the 
corresponding transASP page to a page served by the 
RHCPS sponsor, describing the RHCPS. This link is a 
particularly nonintrusive way to promote the RHCPS 
concept, provided that it is offered in a low-key manner 
40 — and at a strategically situated point in the process, 
where the user is likely to be amenable to education on 
basics of such a service. 

■ The RFQ, bidding and ordering process otherwise 
45 proceeds as in any other project of the transASP. 

■ When the printer generates the proof (s) for the job, 
or contracted component of it, the transASP ac- 
cesses the RHCPS (or a soft-proof ASP) to send 

50 those proofs to the buyer. The RHCPS has all nec- 
essary information to establish that this particular 
user (e- 9- ; the printer) is also using the particular 
transASP. 

55 [0291] Accordingly, before sending the proof the RH- 
CPS offers the possibility of linking it to an order (or order 
component) of the specified transASP. This function is 
readily implemented in the form of a checkbox — one 
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that may appear to linked parties, depending on what 
setup has been put in place. 

[0292J For example, when a printshop operator — us- 
ing the RHCPS interface — enters the intended receiver 
of a proof, a window appears with all the open projects 
in that printshop operator's transASP website (assum- 
ing that the printer has one) corresponding to that buyer, 
i. e. the proof receiver. The printshop operator can then 
select a project (or component) as the one to which the 
proof being sent is linked. 

[0293] Alternatively, the remote proofing process can 
be launched directly from the transASP web page for 
the job. Through a web link, the user directly accesses 
the RHCPS page to create the proof, with all the infor- 
mation about sender, receiver and link to the transASP 
project already filled in. 

■ The remote-proofing workflow is managed by the 
RHCPS as a regular remote proof (upload, down- 
load, then print, approval, etc.). The only difference 
is that, when there is a change in the proof status, 
the data about the new status is sent to the 
transASP system for use in updating the project sta- 
tus. 

■ Printers or buyers, or both, can consult the remote- 
proof status through the transASP website or RH- 
CPS. As will now be clear, in accordance with the 
invention the two are crosslinked — in other words, 
from the transASP site, when accessing the proof- 
ing status of a project, the user should be able to 
access the RHCPS page for that proof; and vice 
versa. 

[0294] Workflow is very similar if the entree to the RH- 
CPS is through a different sort of provider — e. g. a soft- 
proof or network ASP. 

(b) Interface — The following interfaces are de- 
fined. Parallels to the arrangements for the soft- 
proof ASP should now be recognized. 

■ an interface for retrieving information on open 
projects for a certain pair of users — printer and 
buyer 

(Implementation calls for a well-defined 
way of mapping users between the RHCPS us- 
er space and the transASP user space.) 

■ a programmatic interface to allow the creation 
of remote-proofing jobs and f illing-in part of the 
information 

(This is a user-operational facility for "pro- 
gramming in" new jobs, actually data entry.) 

■ a method for linking proofs with transASP 
projects or components — i^e. a job (or com- 
ponent) identif ier that can be stored in the proof 
job ticket and vice versa; 



■ an interface for retrieving information on status 
of a certain proofing job, so that it can be dis- 
played in the transASP's site 

(This interface should support two kinds 
5 of operating modes: synchronous, i. e. status 

queries about a certain proof; and event-trap- 
ping, L_e. automatic update whenever status of 
a certain proof job changes.) 

10 [0295] Some transASPs, as well as the other ASP 
types, may have a tendency to respond to marketplace 
pressures by expanding their services beyond the orig- 
inal and natural areas of interest — and perhaps talent 
— of their operators. The present invention can relieve 

15 them of that, fostering competition without redundancy 
(in particular wasteful, inefficient redundancy). 

(c) Additional transASP features — Advantageous- 
ly the user sees some new elements in the 

20 transASP website. One of these is a new RHCPS 
proof type added to the prepress parameters in the 
project or component description, preferably with 
links from that page to descriptions of the RHCPS. 

25 [0296] Also preferably added is a new display area 
within the previous project-status tabulations — to dis- 
play remote-proofing status of the various components. 
This area displays summarized status and log-in infor- 
mation for the proofs, and provides links for access to 

30 the proof itself and its more-detailed status in the RH- 
CPS. 

(d) Additional RHCPS features — Conversely, for 
an RHCPS user who creates and uploads a proof 

35 into the system, if the user is also a transASP user, 
the RHCPS opens a window showing al! the user's 
open projects — with that transASP — correspond- 
ing to the intended. 

40 [0297] The RHCPS window showing proof status also 
provides a link to the transASP website page that has 
data on the related transASP project. If a proof relates 
to a transASP project, the project or component identi- 
fier is stored in the job ticket. 

45 

7. CONTENT AND TRANSACTION 
STANDARDIZATION FORMATS 

[0298] Because the number of parameters to be 
so brought under control as between different printing sys- 
tems is high, this topic is potentially encyclopedic. Com- 
prehensive presentation of all those variables, however, 
would be of little service to a person of ordinary skill in 
the art, because this part of the RHCPS operation simply 
55 comes down to a massive technological-bookkeeping 
problem. 

[0299] On the other hand, since that problem is rather 
openended and does involve many variables it is one 
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that can leave the person of ordinary skill groping for a 
solid place to begin. To avoid any need for extensive trial 
and error, there follows below a presentation of a pre- 
ferred accounting methodology, together with selected 
examples, providing a clear picture of the approach s 
adopted by the present inventors. 

(a) Data subdivision, standard formatting, and re- 
striction — The fundamental orientation begins with 
use of two industry-standard formats for, respec- io 
tively, document appearance and processing infor- 
mation. Here "appearance" encompasses color, 
layout, and content — which in turn means all the 
graphic objects (text, images, graphics) with their 
correct respective fonts and dimensions. 15 

[0300] Processing information includes printing con- 
ditions and settings — the printer model and all param- 
eters peculiar to that model, the printing-medium type, 
resolution for each image, and the print quality (and 20 
printmode). The appearance and processing data are 
complementary: to perform remote proofing, both are 
required. 

[0301] While appearance information is carried in a 
special form of the industry-standard Adobes Portable 25 
Document File ("PDF"), the processing information is 
held in a job ticket — for which the standard Job Defi- 
nition Format ("JDF") is used. Thus the JDF job ticket is 
part of the data exchange, but is a separate entity from 
the appearance information. 30 
[0302] This division of the data greatly facilitates any 
needed proof retargeting, jje. changing printer-setting 
characteristics to use a different printer model or medi- 
um. Retargeting should be performed at the proof orig- 
inator site, as suggested in the previously mentioned Jo- 35 
dra patent document; however, the JDF should be con- 
figured to accommodate information relevant to different 
printer models, so that the system in the originating site 
need not be told the specific printer model that will be 
used in the receiver's site. 40 
[0303] Key to the most highly preferred embodiments 
of the invention is use of these standard formats with, 
in essence, reduced parameter sets — that is to say, 
with: 

45 

■ entries in many standard fields prohibited or ig- 
nored, and 

■ only limited ranges or discrete values, of the respec- 
tive variables, permitted or accepted in certain other 50 
standard fields. 

[0304] For several reasons this has been found great- 
ly preferable to creating a custom format with only the 
desired fields present. 55 

(b) Additional nomenclature — The PDF and JDF 
together constitute the data exchange or "proofing 



file". Some workers in the industry have come to in- 
stead call this computer-readable file simply the 
"proof" — but in the present text and appended 
claims the more traditional usage is followed, l_e. 
the word "proof refers to the hardcopy document 
or on-screen computer image that is directly visible 
to the human eye. 

[0305] In a specific implementation of the RH CPS, a 
particular entity may have the ability to act as an origi- 
nator or a receiver; however, it is convenient for the 
specification to view them as separate entities. A routing 
service such as a network ASP may add information to 
enable or facilitate transmission from an originator to a 
receiver, but any such changes must be transparent to 
the requirements of the data exchange — in other 
words, data both into and out from the routing service 
should comply with ail rules established for the ex- 
change. 

[0306] To avoid ambiguity the terms "local" and "re- 
mote" sometimes require a point of reference. For 
present purposes "local" usually refers to the location of 
the generator of a proofing file; hence unless otherwise 
specified or suggested by context a "local proof" is one 
printed (or viewed on-screen) in the same location 
where its proofing file is generated; and a "local proofing 
file" is a proofing document generated in a local system 
and susceptible to transmission through the RHCPS to 
a receiver . 

[0307] Correspondingly unless otherwise specified 
"remote" refers to the location of the receiver, and a "re- 
mote proofing file" is one that has been received through 
the RHCPS by the entity "remote" from the originator 
(the "local" entity). A hardcopy proof physically printed 
at that remote location is accordingly a "remote proof"; 
hence the phrases "remote proofing", "remote hardcopy 
proofing service" etc. 

(c) Proof types — It is important that the RHCPS 
be able to handle not only single-page proofs but 
also signature proofs (sometimes called "imposition 
proofs"). Although consistent, accurate remote 
hardcopy color proofing of page modules is ex- 
tremely useful and valuable in itself, the power of 
the invention is greatly expanded by incorporation 
of signature-proofing capability. 

[0308] Accordingly the proofing data contain (in the 
PDF) information on the contents of each page, and (in 
the JDF) layout information describing the signature 
scheme to be used in printing the document on a press. 
In preferred embodiments of the invention, the proof 
generator can produce two types of proofs: page, and 
signature. 

[0309] The difference between them is not in the 
proofing data, but rather in how the layout information 
is used by the recipient's proofing device when printing 
the proof: 



30 



59 



EP 1 262 748 A2 



60 



■ For page proofs the device may use the layout in- 
formation to print the proof, but is not required to do 
so. If the proofing device cannot print the signature 
(s) as described in the layout, it is not required to so 
inform the user. 

■ For signature proofs the proofing device must use 
the layout information to print the proof. If the proof- 
ing device cannot print the signature(s) as de- 
scribed in the layout (due, most commonly, to me- 
dia-size limitations) it must inform the user and pro- 
vide different options for printing the proof or can- 
celing it. The specific user interface is device de- 
pendent. 

[031 0] For example, suppose that an originating entity 
creates a proofing file for an eight-A4-page document, 
describing an eight-up signature that will be used in the 
press. If those proofing data are sent to an A3-size 
proofer, the behavior may depend on the type of proof 
requested: 

■ If a page proof was requested, the proofer can print 
four A3 sheets, each containing two of the original 
document pages. To group the document pages, 
the device may use the information in the layout da- 
ta to ensure that the two A4 pages printed in each 
sheet are adjacent in the signature; or it may use 
any other algorithm — such as printing pages in the 
order in which they appear in the assembled docu- 
ment. 

■ If a signature proof was requested, the proofer is- 
sues a warning informing the user that it cannot print 
the signature because that would exceed the max- 
imum page size of the device. It may offer the user 
several options, such as dividing the signature (til- 
ing), scaling down the whole form proof or reverting 
to a page proof. 

(d) PDF/Proof contents — To ensure that the output 
proof can be printed consistently in different devices 
it is helpful to strictly define the characteristics of the 
file. PDF is a very powerful, general-purpose for- 
mat, whose features and functionality are far more 
versatile than the RHCPS can use; hence many of 
these features and functionality are restricted. In 
this document a file that complies with these re- 
quirements is sometimes called a "PDF/Proof file". 

[0311] Compliance with PDF/Proof restrictions does 
not ensure output hardcopy consistency. A receiver 
must process the data in a specific way to achieve it. 
[0312] Thus a conforming PDF/Proof file is a PDF in 
which are found those features necessary for the ex- 
change of proofing data and to enable output consist- 
ency at any receiving entity. Receiving entities must en- 
sure output consistency for files conforming to PDF/ 
Proof constraints. 



[0313] In the embodiment now preferred, a PDF/Proof 
file must be a valid PDF 1 .3 file, as described in the " PDF 
Reference Manual / Version 1 .3 ". Thus any requirement 
of PDF 1 .3 or higher is also a requirement of PDF/Proof 

5 but is not further mentioned or repeated below. 

[0314] Although nonprinting-related PDF constructs 
— such as annotations and thumbnails — might be 
present in a PDF/Proof file, they are ignored by the re- 
mote-proofing entities and consequently are not includ- 

10 ed in this discussion of the file format. (It can make 
sense to use these features if it is desired to use other 
PDF standard tools in the workflow.) In particular, spec- 
ification of the PDF/Proof format contemplates only the 
objects in the pages tree, catalog, and file information 

15 dictionaries in a PDF. 

[0315] Advantageously there are two versions of 
PDF/Proof, defined relative to a raster image processor 
("RIP") that is currently used in the preferred printing 
systems to prepare images for the printing engine: 

20 

■ "PDF/Proof- Image" supports only "postRIPped" re- 
mote-proofing workflow. 

■ "PDF/Proof-Object" supports both "postRIPped" 
25 and "preRlPped" remote-proofing workflow. As 

these relationships suggest, PDF/ProoMmage is a 
subset of PDF/Proof-Object; L_e. any file that com- 
plies with PDF/Proof- Image also complies with 
PDF/Proof-Image. 

30 

[0316] The presentation of exemplary PDF/Proof re- 
strictions will begin now with "PDF/Proof -Image ". 
[0317] All the components of the proof contents are 
contained in the body of a single PDF/Proof-Image file. 
35 it is not permitted to present only as an embedded file 
any component required to process the proof contents. 
[0318] To help see how to implement the general 
rules, following are only just a few examples of several 
dozen constraints that make up a PDF/Proof- Image 
40 specification. This part of the present document as- 
sumes familiarity with parameter and field names (such 
as "DefaultForPrinting", "Outputlntent", "ExtGState", 
"MediaBox", etc.) defined in the PDF 1 .3 specification. 
[0319] As a consequence of the contents-in-body re- 
45 quirement last stated above, streams cannot reference 
external files. That is to say, the F, FFilter and FDecode- 
Params entries in a stream dictionary cannot be used. 
[0320] As examples of constraints to contents, each 
page can contain only image objects; they can be either 
50 external images (so-called "image "XObjects") or inline 
images. The only commands allowed in a 
page "Contents" stream are: 

q, Q: save and restore the graphics state; 

55 cm: modify the current transformation matrix; 

Do: include an external object (so-called 

"XObject") — and images are the only 

XObject types allowed; 
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Bl, ID, El: inline images 

[0321 ] As examples of constraints to bounding boxes, 
each page object must include a MediaBox and Trim- 
Box; MediaBox may be included by the object-oriented 
programming concept known as "inheritance". A Crop- 
Box or BieedBox, or both, may also be included in the 
page. If the BieedBox is present, the TrimBox will not 
extend beyond the BieedBox boundaries. If the Crop- 
Box is present, the TrimBox will not extend beyond the 
boundaries of the CropBox. 

[0322] As examples of constraints to color, the only 
color spaces allowed are DeviceCMYK and DeviceG- 
ray; ail the images (either inlined in the contents stream 
of pages or in an image XObject) must be in DeviceC- 
MYK, DeviceGray or Indexed color space. If Indexed 
color is used, the base color space should be DeviceG- 
ray or DeviceCMYK. 

[0323] Still as to PDF/Proof-Image constraints — as 
examples of restrictions on Identification, a PDF/Proof- 
Image file is so identified using the 
HWEP_PDFProofVersion key in the Info dictionary; the 
type of a HWEP_PDFproofVersion key is string, and its 
value is ( HWEPProoflmageO.1 ). 
[0324] Turning now to PDF/Proof -Object constraints, 
a PDF/Proof -Object file must meet additional require- 
ments, on top of the requirements described in the " PDF 
Reference Manual, Versionl .3 ". As examples of data- 
structure restrictions, all components of the proof con- 
tents must be contained in the body of a single PDF/ 
Proof -Object file — and this refers to all the PDF re- 
sources (as described under "Resource Dictionaries" in 
the previously mentioned PDF Manual ) used in the file 
including all fonts, font metrics, font encodings, full res- 
olution images, ICC profiles etc.; and print elements 
must be included in the file. 

[0325] As examples of content restrictions, operators 
not allowed in the Contents stream for a page are PS 
(PostScript code embedded in page contents); BX, EX 
(compatibility operators): and in general any operator 
not described in the PDF Manual . Images cannot have 
the OPI entry in the image dictionary set. If the Alter- 
nates entry in the dictionary is set, none of the alternate 
images can have the DefaultForPrinting entry set to 
true: that is, the base image is the one that must be used 
for printing the proof. 

[0326] As examples of constraints to bounding boxes, 
the same rules apply as stated above for PDF/Proof- 
Image. As examples of constraints to color, a color ren- 
dering intent must be specified for the contents for all 
pages; rendering intent can be specified in the 
ExtGState resource or in the Image dictionary for imag- 
es. Color space and Identification restrictions are gen- 
erally as stated above for PDF/Proof-Image. 

(e) JDF contents — As suggested in earlier discus- 
sion, a JDF job ticket is required to ensure that the 
front end of the remote printing system processes 



the proofing file with the correct settings : compatible 
with those used when printing the proof on the local 
file, in order to ensure output consistency. Specifi- 
cation of the "JDF Job Ticket" requirements for re- 
s mote proofing are based on the " JDF Specification 
Release 1 .0 ", with a few variant details (names and 
permitted values of some elements in the resource 
elements). 

w [0327] That specification covers two areas: process- 
es allowed in the remote-proofing JDF job ticket, and 
resources (and their syntax) required for those process- 
es. The specification does not cover other areas in that 
job ticket, such as customer-related information, or au- 
15 dit. Although such information may appear in the job 
ticket it is not required — for purposes of this invention 
— that originating entities generate it or receiving enti- 
ties process it. 

[0328] The RHCPS is an implementation of the JDF 
proofing process and inherits the characteristics of that 
process. Extensions are added.to support the specifics 
of the remote-proofing use case andthermal-inkjet print- 
ing technology. Also, due to limitations on printing de- 
vices and to simplify implementation, just as for the PDF 
some restrictions are desired on possible values and 
characteristics. The JDF job ticket should have one 
node (the root node) specifying the Proofing process. 
[0329] For examples of constraints as to resources, if 
the ColorantControl, ColorPool, or ColorSpaceConver- 
sionParams resources are present in the proof ing-input 
resources they are ignored in the proofing file; the color 
space used (press CMYK) has to be fully defined using 
an ICC profile. The Layout resource is required if the 
ProofType field in the ProofingParams resource is set 
to Imposition (i. e. signature). 

[0330] As to constraints concerning media, since the 
JDF job ticket is generated without knowing on which 
device or devices the hardcopy proof will be printed, this 
resource is only a hint. Behavior when the media avail- 
able on the proofing device fail to match the require- 
ments in this resource is device dependent. As exam- 
ples of constraints on interpretation of each of the fields 
in the Media resource, Dimension is not required but if 
present describes the minimum printing-medium dimen- 
sion required to print the proof. If the proof type is set to 
Imposition, this is the size of the signature; if it is instead 
set to Color, this is the size of the largest page in the 
document. 

[0331 ] As examples of constraints to the ProofingPar- 
ams resource, ProofType is required and describes the 
type of proof requested. ColorConceptual or Contone is 
used for page proofs and Imposition of signature proofs. 
Halftone proof types are not supported. Several param- 
eters that are just ignored if present include ImageView- 
ingStrategy, DisplayTraps, and Proof erProfile. 
[0332] The document Run List describes the docu- 
ment that is to be proofed and includes a link to the doc- 
ument contents file. In the initial version of the RHCPS 
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that is the current most highly preferred embodiment, 
proofing is restricted to documents contained in a single 
PDF/Proof file. In consequence there are some restric- 
tions on the characteristics of the document RunList. 
[0333] For example Npages, if defined, should be set 
to the total number of pages in the document; and Run 
can only contain one RunElement. Examples of con- 
straints on the RunElement include these: if EndOfDoc 
or Dynamiclnput is present, the field contents are ig- 
nored. The RunElement can contain only one RunSepa- 
ration. 

[0334] Yet further limits in turn apply to RunSepara- 
tion, including its LayoutElement, and still further con- 
straints apply to contents of the LayoutElement. RunList 
"marks" are not supported in the present version of the 
RHCPS. If a proof must include printing marks, they 
should be included in the page descriptions in the proof- 
ing file. 

[0335] For local proofs, the two components of the 
proofing data are packaged using the MIME File Pack- 
aging method descried in Appendix A of the " JDF Spec- 
ification Release 1 .0 ". References to external files are 
allowed neither in the job ticket nor the document con- 
tents. 

[0336] For remote proofs, the two components can be 
packaged using the same MIME method. It is also pos- 
sible that the job ticket contains only a URL specifying 
the location of the document contents portion of the 
proof data. Constraints on URL type can be helpful. 
[0337] Again, the foregoing specification details are 
only examples of some dozens of such restrictions ac- 
tually used. From the considerable length of this merely 
exemplary presentation it will be clear why the full set is 
not detailed here. Those presented are intended to con- 
vey a clearer understanding of the reduced-parameter- 
set approach to use of industry-standard PDF and JDF 
formats. 

[0338] The above disclosure is intended as merely ex- 
emplary, and not to limit the scope of the invention — 
which is to be determined by reference to the appended 
claims. 



Claims 

1 . A remote proofing computer system comprising: 

a closed-loop-color remote hardcopy proofing 
service "RHCPS", (1 1 ) that provides an RHCPS 
user interface (2-28) having data (2, 7, 12 and 
16-27) about a printing job to be hardcopy- 
proofed (14, 15); and 

a graphic-arts application service provider 
("ASP", 21-25) that provides a remotely acces- 
sible ASP FTP site or website having data 
about its service; 



RHCPS link (13-15; 2, 7, 12 and 1 6-27) to the ASP 
data when an RHCPS user (12) is also a user of the 
ASP. 

5 2. The system of claim 1 , wherein: 

the closed-loop-color RHCPS is based on a 
printer device (14, 15) that prints and reads a 
calibration pattern, and that returns a calibra- 
te tion report to a user who is in a different location 
(12, 13, 21) from the printer device. 

3. The system of claim 1 , wherein: 

15 the RHCPS link to the ASP data appears only 

if the ASP is an established copartner with the 
RHCPS. 

4. The system of claim 1 , wherein: 

20 

for each user, the link to the ASP data compris- 
es a visible tabulation (2, 7, 12 and 16-27) of 
that user's graphic-arts jobs with the ASP; 
the tabulation comprises an active graphic-arts 
25 dialog window for addition or modification (2, 7, 

1 2 and 1 6-27) of that user's own graphic-arts 
jobs; and 

said modification in the graphic-arts dialog window 
30 comprises an option of deleting that user's own 
graphic- arts jobs. 

5. The system of claim 4, wherein: 



35 the RHCPS maintains data linking each RH- 

CPS user (12) to each ASP (21-25) which has 
such a remotely accessible FTP site or website, 
and with which that user is registered; 
for each user, the RHCPS interface link to the 

40 ASP data appears only for an ASP with which 

that user is registered; and 
for each particular job that a user has associat- 
ed with an ASP, the RHCPS automatically 
routes proof reports and related details to the 

45 user through that ASP rather than to the user 

directly, unless the user specifically instructs 
the RHCPS to the contrary. 

6. The system of claim 1 , wherein: 

50 

the ASP's FTP site or website comprises a user 
interface (2, 7, 12 and 16-27) with said data 
about the ASP services; 
the ASP interface comprises a link to the RH- 
55. c PS interface when an ASP user is also an RH- 

CPS user; 

in the ASP interface, the link to the RHCPS in- 
terface appears only if the RHCPS is an estab- 
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wherein the RHCPS interface comprises an 
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lished copartner with the ASP; 
for each user, the ASP interface link to the RH- 
CPS interface comprises a visible tabulation of 
that user's jobs that are subject to remote hard- 
copy proofing; 5 
the tabulation comprises an active remote- 
hardcopy-proofing (RHCP) dialog window for 
addition or modification of that user's own RH- 
CP jobs; and 

10 

said modification in the dialog window comprises an 
option of deleting that user's own RHCP jobs. 

7. The system of claim 6, wherein: 

15 

for each user, the RHCPS interface link to the 
ASP data appears only for an ASP with which 
that user is registered; and 
for each particular job that a user has associat- 
ed with the RHCPS, the ASP automatically 20 
routes proofing jobs from the user to the RH- 
CPS rather than to another proofing entity, un- 
less the user specifically instructs the ASP to 
the contrary. 

25 

8. The system of claim 1 , wherein: 

the RHCPS user interface and the ASP's FTP 
site or website are for operation by any user se- 
lected from the group consisting of: 30 

a primary customer (12), including but not 
limited to a publisher, printing customer, or 
printing client, 

a buyer representing a primary customer; 35 

a graphic artist (21), 

a printing broker (24), and 

a user that is any hybrid of two or more of 

the preceding four user types: and 

40 

the ASP is selected from the group consisting 
of: 

a printing-brokerage ASP (24), 

a soft-proofing ASP (22), 45 

a private-network ASP (25), and 

an ASP that is any hybrid of two or more of 

the preceding three ASP types. 

9. The system of claim 8, wherein: so 

the RHCPS link to the ASP data also comprises 
access to further service of the ASP other than 
RHCPS procedures: and 

said further service comprises: 55 

if the ASP is a printing-brokerage ASP (24) 
or hybrid thereof, service relating particu- 



larly to transactional matters, 
if the ASP is a soft-proofing ASP (22) or hy- 
brid thereof, service relating particularly to 
generation, checking or approval of a soft 
proof, and 

if the ASP is a private- network ASP (25) or 
hybrid thereof, service relating particularly 
to data transmission or storage. 

10. The system of claim 8, wherein: 

if an RHCPS user is not an established user of 
any particular ASP, of any one type of said three 
ASP types or a hybrid thereof, the RHCPS in- 
terface comprises an RHCPS link to data of ei- 
ther: 

all ASPs which are established copartners 
with the RHCPS; or 

all ASPs of that one type or hybrid, which 
are established copartners with the RH- 
CPS. 

11. A computerized remote proofing method compris- 
ing the steps of: 

operation, by a user (12), of a closed-loop-color 
remote hardcopy proofing service ("RHCPS", 
11) user interface (Figs. 2-28), to gain access 
to data about a printing job to be hardcopy- 
proofed (14, 15); and 

granting, by a graphic-arts application service 
provider ("ASP", 21-25), of access to data 
about the ASP's service; 
said granting being in response to the user's ac- 
tivation of a link (Figs. 13-15; and lower half of 
Figs. 2, 7, 12 and 16-27), within the RHCPS in- 
terface, to a user interface of the ASP; 

wherein the RHCPS user is also a user of the 

ASP. 

12. The method of claim 11, wherein: 

the operating step comprises actions support- 
ing preparation of a remote closed-loop-color 
hardcopy proof, by a printer device (14. 15) that 
prints and reads a calibration pattern and re- 
turns a calibration report to an entity in a differ- 
ent location from the printer device; 
the granting step occurs only if the ASP is an 
established copartner with the RHCPS; and 
the granting step comprises presenting to the 
user a visible tabulation (2, 7, 12 and 16-27) of 
that user's graphic-arts jobs with the ASP. 

13. The method of claim 12, wherein: 
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the presenting step comprises opening an ac- 
tive graphic-arts dialog window for the user's 
addition or modification of that user's own 
graphic-arts jobs; and 

the opening step comprises permitting the user 5 
to delete that user's own graphic-arts jobs, by 
means of the dialog window; and 
further comprising the step of maintenance, by 
the RHCPS, of data linking each RHCPS user 
to each ASP with which that user is registered. 10 

14. A method of operating a closed-loop color remote 
hardcopy proofing service "RHCPS" (11); said 
method comprising the steps of: 

15 

making available a computerized, network- 
based RHCPS operated through at least one 
user interface (2-28); 

for each project of the RHCPS, establishing 
functioning computerized relationships among 20 
the RHCPS and entities that include at least a 
primary customer (12) and a printshop (13); 
enabling the RHCPS or any of said entities to 
initiate a project and thereby define default op- 
erating conditions that determine which of said 25 
entities sees, in the at least one user interface, 
each other one of the entities respectively; and 
regardless of which of the RHCPS or said en- 
tities initiates the project and defines the default 
relationships, reserving to at least one of said 30 
entities an option of redefining operating con- 
ditions to override the default conditions. 

15. The method of claim 14, wherein: 

35 

said at least one of said entities comprises the 
primary customer (12); and 
further comprising the step of making available 
(28) to the primary customer information about 
the option. 40 

16. The method of claim 15, wherein: 

the making-available step comprises including 
in an RHCPS user interface seen by the prima- 45 
ry customer a link (Fig. 28) to terms of the RH- 
CPS, which include the information about the 
option. 

17. The method of claim 14, wherein: so 

the reserving step comprises enabling the pri- 
mary customer to redefine which of the entities 
the primary customer can see; 
whereby the method stimulates competition 55 
while tending to deter redundancy, among en- 
terprises in the printing industry. 
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